[prev in list] [next in list] [prev in thread] [next in thread]
List: mingw-notify
Subject: MinGW-notify digest, Vol 1 #869 - 3 msgs
From: mingw-notify-request () lists ! sourceforge ! net
Date: 2004-08-03 3:31:50
Message-ID: E1Brq5p-00015R-Sr () sc8-sf-list1 ! sourceforge ! net
[Download RAW message or body]
Send MinGW-notify mailing list submissions to
mingw-notify@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/mingw-notify
or, via email, send a message with subject or body 'help' to
mingw-notify-request@lists.sourceforge.net
You can reach the person managing the list at
mingw-notify-admin@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of MinGW-notify digest..."
This list is used to send updates of submitted patches, bug reports and file \
releases. You are discouraged from posting to this list. If you wish to unsubscribe \
you can do so at https://lists.sourceforge.net/lists/listinfo/mingw-notify.
Today's Topics:
1. [ mingw-Patches-1000966 ] Missing Crypto API types and defines (AES & HMAC) \
(SourceForge.net) 2. [ mingw-Bugs-939155 ] -Wformat doesn't know %uI64 is for \
64-bit, not %ull (SourceForge.net) 3. [ mingw-Bugs-1001932 ] gcc 3.3 - 3.4 SSE V4sf \
misalignement (SourceForge.net)
--__--__--
Message: 1
To: noreply@sourceforge.net
From: "SourceForge.net" <noreply@sourceforge.net>
Date: Mon, 02 Aug 2004 02:49:04 -0700
Subject: [Mingw-notify] [ mingw-Patches-1000966 ] Missing Crypto API types and \
defines (AES & HMAC)
Patches item #1000966, was opened at 2004-07-31 10:07
Message generated for change (Comment added) made by dannysmith
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=1000966&group_id=2435
Category: w32api
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ed Schaller (schallee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing Crypto API types and defines (AES & HMAC)
Initial Comment:
BLOBHEADER:
-----------
Typdef for _PUBLICKEYSTRUC which is defined already.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/blobheader.asp
AES defines for algorithms and providers:
-----------------------------------------
The defines for CALG_AES* depend on the ALG_SID_AES*.
ALG_SID_AES*
seem to be undocumented on msdn (at least the search
for them returns
nothing although we all know how useful msdn's search
is). Also,
MS_ENH_RSA_AES_PROV according to Microsoft is
"Microsoft Enhanced RSA and
AES Cryptographic Provider". It may be that in win2003
server (which I do
not have access to) but it is certainly not in winxp. I
have defined it
in the patch to be "Microsoft Enhanced RSA and AES
Cryptographic Provider
(Prototype)" which is what it is defined as in winxp.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/microsoft_aes_cryptographic_provider.asp
HMAC_INFO HP_HMAC_INFO:
-----------------------
Used to do HMACs. Not that MS's implementation is
usable for me (key
has to be a symmetric session key of a symmetric
algorithm and therefore
is limited in it's possible sizes). I have a hmac
implementation that
uses MS's hashes if anyone wants it.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/hmac_info.asp
CALG_SHA1:
----------
Same as CALG_SHA.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/cryptcreatehash.asp
----------------------------------------------------------------------
> Comment By: Danny Smith (dannysmith)
Date: 2004-08-02 21:49
Message:
Logged In: YES
user_id=11494
Thanks
Please have a look at the Changlog and submit a changelog
entry in that style.
Danny
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=1000966&group_id=2435
--__--__--
Message: 2
To: noreply@sourceforge.net
From: "SourceForge.net" <noreply@sourceforge.net>
Date: Mon, 02 Aug 2004 02:59:40 -0700
Subject: [Mingw-notify] [ mingw-Bugs-939155 ] -Wformat doesn't know %uI64 is for \
64-bit, not %ull
Bugs item #939155, was opened at 2004-04-21 21:01
Message generated for change (Comment added) made by dannysmith
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=939155&group_id=2435
Category: gcc
Group: None
Status: Open
> Resolution: Later
Priority: 5
Submitted By: Wim Heirman (wheirman)
Assigned to: Danny Smith (dannysmith)
Summary: -Wformat doesn't know %uI64 is for 64-bit, not %ull
Initial Comment:
In msvcrt, the length modifier in a printf()-format for
long long datatypes is "I64", not "ll" like in glibc. However
gcc doens't know this, and complains that the format
string and arguments of a printf-function don't match.
----------------------------------------------------------------------
> Comment By: Danny Smith (dannysmith)
Date: 2004-08-02 21:59
Message:
Logged In: YES
user_id=11494
This is fixed in mingw relase of gcc-3.4.1, but not yet in
official FSF sources. It is low priority for me, so if someone
wants to follow up with a submission to GCC, feel free. The
patch I put into mingw local release probably has way to
many ifdef __MINGW32__'s to be palatable to GCC, so it will
need some work.
Danny
----------------------------------------------------------------------
Comment By: Ed Schaller (schallee)
Date: 2004-08-01 07:08
Message:
Logged In: YES
user_id=2001
Ok, now I feel like a moron. Sorry. Yes I can confirm that
3.4.1 does fix the issue. I feel more like a moron in that I
downloaded and installed it to check some other problems
before submitting a patch but didn't check this one.
----------------------------------------------------------------------
Comment By: Danny Smith (dannysmith)
Date: 2004-07-31 10:40
Message:
Logged In: YES
user_id=11494
Have you tried with mingw release of gcc-3.4.1?
Danny
----------------------------------------------------------------------
Comment By: Ed Schaller (schallee)
Date: 2004-07-31 07:48
Message:
Logged In: YES
user_id=2001
Likewise for %I64u. Should this one be reported to gcc folks
instead of mingw?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=939155&group_id=2435
--__--__--
Message: 3
To: noreply@sourceforge.net
From: "SourceForge.net" <noreply@sourceforge.net>
Date: Mon, 02 Aug 2004 04:04:40 -0700
Subject: [Mingw-notify] [ mingw-Bugs-1001932 ] gcc 3.3 - 3.4 SSE V4sf misalignement
Bugs item #1001932, was opened at 2004-08-02 13:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1001932&group_id=2435
Category: gcc
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Italianate (lorenzoseno)
Assigned to: Danny Smith (dannysmith)
Summary: gcc 3.3 - 3.4 SSE V4sf misalignement
Initial Comment:
gcc version: both core 3.3.1 and 3.4.0
MinGW version: 3.1.0
mingw-runtime: 3.3
w32api 2.5
ld version 2.13.90
OS: W2k sp4
When using SSE extension, if you declare any v4sf
vector __attribute__ ((aligned (16))) amid globals,
each one is allocated to the (shared) address 0x0,
which is a 16 byte-aligned location so that subsequent
movaps doesn't crash the run (but the code doesn't
work at all, of course).
If you declare the previous v4sfs amid the main
variables, the generated addresses are different, but not
16 bytes aligned (they end with an 0x8, in my run).
Subsequent movaps (automatically generated by gcc or
manually coded) will crash the run.
The code can be made working, but only manually
coding movups instead of movaps (in asm()).
The same things happen if you suppress the attribute -
aligned declaration.
The gcc 3.3 linux version works instead fine, it
automatically generates 16 byte-boundary-aligned v4sf
locations, w/o the need of declaring alignement
attributes.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1001932&group_id=2435
--__--__--
_______________________________________________
MinGW-notify mailing list
MinGW-notify@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-notify
End of MinGW-notify Digest
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic