Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clean up of warnings (tested on clang). #9

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

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?

@@ -185,7 +185,7 @@ static int tpl_mmap_file(char *filename, tpl_mmap_rec *map_rec);
static int tpl_mmap_output_file(char *filename, size_t sz, void **text_out);
static int tpl_cpu_bigendian(void);
static int tpl_needs_endian_swap(void *);
static void tpl_byteswap(void *word, int len);
static void tpl_byteswap(void *word, ssize_t len);
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.

@@ -302,7 +306,7 @@ char *calc_field_addr(tpl_node *parent, int type,char *struct_addr, int ordinal)
align_sz = tpl_types[type].sz;
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.

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 join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants