#3638: Compilation errors for 1.6
-----------------------+----------------------
Reporter: grarpamp | Owner: mutt-dev
Type: defect | Status: new
Priority: major | Milestone: 1.6
Component: mutt | Version: 1.5.21
Resolution: | Keywords:
-----------------------+----------------------
Comment (by kevin8t8):
grarpamp wrote:
> imap/imap.c:283: warning: dereferencing type-punned pointer will break
strict-aliasing rules
> imap/imap.c:1355: warning: dereferencing type-punned pointer will break
strict-aliasing rules
Could you compile the latest tip again and check the line numbers. I'm
not seeing anything too crazy at these lines.
> imap/message.c:63: warning: unused variable 'buf'
> pop_lib.c:67: warning: implicit declaration of function 'ntohs'
These are both fixed in default tip now. I added "#include
<netinet/in.h>" to pop_lib.c because that's what the other mutt sources
that use the ntoh functions include.
> main.c:75: warning: string length '558' is greater than the length
> '509' ISO C90 compilers are required to support
I don't think we need to fix this one.
> ascii.h:35: warning: 'ascii_tolower' declared inline after being called
> ascii.h:35: warning: previous declaration of 'ascii_tolower' was here
This may be an older gcc warning. I'm not seeing the warning and don't
see anything particularly wrong with the code. As far as I know it's
perfectly legal to use ascii_tolower() inside the ascii_strlower()
definition even though it's later declared inline in ascii.c.
> I also get this difference when using LDFLAGS=-static ...
>
> - checking for idna_to_unicode_8z8z... yes
> - checking for idna_to_unicode_8z8z... no
>
> - checking for idna_to_ascii_8z... yes
> - checking for idna_to_ascii_8z... no
>
> - checking for idna_to_ascii_lz... yes
> - checking for idna_to_ascii_lz... no
Would you try out the configure-idna-fix.patch I just uploaded to this
ticket and see if that helps. My system is currently not set up with
all the needed static libraries so I can't test the fix myself.
> lib.c:569: warning: warning: mktemp() possibly used unsafely; consider
> using mkstemp() mkstemp(3) actually creates the file returning fd,
> thus securing against races. I'd consider having configure test for it
> and implementing it in muttlib.c.
I don't have anything useful to add to this discussion. It looks like
an argument was made to keep mktemp and ignore the warning. If I
misunderstood please clarify.
This seems like a discussion that can go around and around, and if there
really isn't a "resolution" it doesn't seem useful to keep the bug open
because of it.
--
Ticket URL: <http://dev.mutt.org/trac/ticket/3638#comment:13>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
