[Help-gnutls] Re: gnutls 2.3.4 doesn't copile using MinGW

[Simon Josefsson]

Massimo Gaspari <massimo.gaspari at alice.it> writes:

> Simon Josefsson wrote
>> Huh!  The day of month is missing.  This suggest a bug in strftime on
>> Windows, the code reads:
>>
>>       if (gmtime_r (&tim, &t) == NULL)
>> 	addf (str, "error: gmtime_r (%d)\n", t);
>>       else if (strftime (s, max, "%a %b %e %H:%M:%S UTC %Y", &t) == 0)
>> 	addf (str, "error: strftime (%d)\n", t);
>>       else
>> 	addf (str, _("\t\tNot Before: %s\n"), s);
>>
>> In other words, the '%e' field doesn't work.  Possibly '%d' is more
>> portable, from the man page:
>>
>>        %d     The day of the month as a decimal number (range 01 to 31).
>>
>>        %e     Like %d, the day of the month as a decimal number, but a leading
>>               zero is replaced by a space. (SU)
>>   
> I read the MSDN documentation and as far as I understand  %e is not
> supported by the Microsoft C Runtime library, it's not listed in the
> available format specifiers.
> So because MinGW uses the Microsoft's runtime-lib I got that issue,
> also Visual C should have it.

Right.  I've documented this in gnulib in:

http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=doc/posix-functions/strftime.texi;hb=HEAD

> Anyway I got the latest version as you suggested,
> gnutls-2.3.6.tar.bz2. I see that you changed the %e specifier using
> %d.

Yes, it should be more portable, and using %e is not that important in
this case.

> After unpacking I changed the vasprintf to gnutls_vasprintf and
> nothing else. With just this single modification make terminated
> successfully.

Great!

> So the alloca isssue disappeared.

Yes, I removed all uses of alloca in the code, see the NEWS file.

> I observed a thing. When I did make for the very first time I didn't
> get the documentation building issue, but then if I do
>
> make clean
> make
>
> I get the doc building issue. Does the "make clean" really delete all
> the modified and/or created files? May be not. Anyway I'm going to try
> to update the texinfo (f a new MinGW package is available).

Hm, interesting, I'll see if I can reproduce this.  It may be that this
is intentional, but I'm not sure.

> <                       ASCII:
> 0;09..`.H...E....0*0(..+.........https://www.verisign.com/rpa
> ---
>>                       ASCII: 
> 0;09..`.H..øE....0*0(..+.........https://www.verisign.com/rpa
> FAIL: pathlen
...
>
> Is still pathlen. There is a ø difference!!! Tomorrow I'll try to
> understand what that test is doing.

This seems like a isprint() problem.  Windows probably think ø is a
printable character, and it is difficult to argue with that.  The code
needs to use a ASCII-only isprint function here, so that the output is
consistent regardless of locale it is run in.

> Because the issue is in the runtime lib I think that without a patch
> neither MinGW nor Visual C can pass the test. But I think you couldn't
> care less of Visual C :-),  is it?

Nah, we should support it when feasible... some of the issues you have
brought up affect other platforms too, so they are bugs in gnutls.

>> Nope, this is not related.  The problem here is that if the platform has
>> this bug, gnutls will print non-ascii characters when printing X.509
>> subject/issuer names.  We should fix that too, but it is more difficult
>> to do if nobody can help debug any proposed fix.
>>   
> I can help you  for the  MinGW environment. Or, at least, I would. I
> don't know if I'm really helping you or not. :-)

You are helping a lot!  We have fixed several things based on your
report.

> So the last issue for compilation is the vasprintf. Are you going to
> change something? May be the least is to add a comment to the
> installation instruction.

Yes, but I need to look into how we can solve this in a clean/portable
way.  Meanwhile we could document this... although this discussion in
the mailing list archive may be sufficient.

/Simon