Skip to content
This repository was archived by the owner on Nov 29, 2025. It is now read-only.

Conversation

@pbosetti
Copy link

@pbosetti pbosetti commented Jul 4, 2014

I tried to cleanup all of the warnings for implicit conversions. I understand that it can be a non-trivial task, for the formability issues related to type conversion can be hard to spot at a first look on the code. For this reason, I am not 100% sure I've done all the necessary edits to your code.
Nonetheless, I think that checking and cleaning up type conversion warnings would be a desirable task, giving users some larger confidence in the code reliability.

Of course, thanks for sharing such a helpful piece of software.

@troydhanson
Copy link
Owner

Hi Paolo. Unfortunately ssize_t does not exist in some Windows compilers. Just yesterday I just had this issue on my uthash project where we removed ssize_t. In order to merge this, we'd need to have some kind of ifdef that provided an alternative for Windows. I don't use clang myself, but I've had patches before, that were just there to quiet clang warnings. Unfortunately they tend to obfuscate the code and make it more fragile. For example the first case where an int being replaced by ssize_t is misleading, because I know that the int is in fact a small positive number (so maybe it should be unsigned int - but what benefit is there in using size_t?). But I have no way to tell clang that. In other cases, explicit types like uint32_t are used in tpl because tpl casts between fixed-length buffers from the the binary tpl image to them. So that is how we guarantee we can memcpy between the tpl image and memory. Does clang have features where you can give it hints that help it understand why certain types are used the way they are?

src/tpl.c Outdated
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The len here is always a small positive number like 4 or 8.

@pbosetti
Copy link
Author

pbosetti commented Jul 7, 2014

Hi Troy,
this is exactly the kind of answer I was expecting ;) and thanks for clarifying those points. Personally, my experience with clang is that its somehow pedantic code analysis is in fact rather useful in avoiding bugs, so I tend to cleanup the warnings list to the largest extent.
I can reverse that commit and create a new one respecting your comments, then submit a new PR. I'm probably going to do this this morning. I suspect that I'd need some iterations, here...
Thx,
-P.

Accepted Troy's suggestions. In tpl_dump(), cast to int from a write() return value
is performed after checking for INT_MAX.
Also, avoiding use of ssize_t (in favour to size_t or long+cast) to be windows
friendly.
@tbeu
Copy link
Collaborator

tbeu commented Dec 7, 2017

I resolved the conflict but am unable to push to your branch. Can you please enable.

break;
}
offset = ((uintptr_t)prev->addr - (uintptr_t)struct_addr)
offset = ((size_t)prev->addr - (size_t)struct_addr)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I rather see the ptrdiff_t type here. See https://www.viva64.com/en/a/0050/ for example.

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wunused-variable"
static const char tpl_S_fmt_chars[] = "iucsfIUjv#$()p"; /* valid within S(...) */
#pragma clang diagnostic pop
Copy link
Collaborator

@tbeu tbeu Dec 7, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

VS reports warning C4068: Unknown Pragma, thus you probably should wrap the pragma in #ifdef.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants