From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3270 Path: news.gmane.org!not-for-mail From: "Z. Gilboa" Newsgroups: gmane.linux.lib.musl.general Subject: sign (in)consistency between architectures Date: Wed, 1 May 2013 13:05:03 -0400 Message-ID: <51814B3F.4040005@eservices.virginia.edu> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------080801040302000301050801" X-Trace: ger.gmane.org 1367427920 17258 80.91.229.3 (1 May 2013 17:05:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 May 2013 17:05:20 +0000 (UTC) To: Original-X-From: musl-return-3274-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 01 19:05:20 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UXaT0-0006B0-5x for gllmg-musl@plane.gmane.org; Wed, 01 May 2013 19:05:18 +0200 Original-Received: (qmail 32494 invoked by uid 550); 1 May 2013 17:05:17 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 32486 invoked from network); 1 May 2013 17:05:16 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 X-Originating-IP: [128.143.170.107] Xref: news.gmane.org gmane.linux.lib.musl.general:3270 Archived-At: --------------080801040302000301050801 Content-Type: multipart/alternative; boundary="------------020008000403030000010200" --------------020008000403030000010200 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Greetings, The current architecture-specific type definitions (arch/*/bits/alltypes.h) seem to entail the following inconsistent signed/unsigned types: type x86_64 i386 ------------------------------- uid_t unsigned signed gid_t unsigned signed dev_t unsigned signed clock_t signed unsigned For *uid_t* and *gid_t*, the GNU documentation specifies /_unsigned int_:// //http://www.gnu.org/software/libc/manual/html_node/Reading-Persona.html#index-uid_005ft-3309/ For *dev_t*, the specification requires /_an integer type no narrower than int//_/: and given the value it is expected to hold (file device numbers), making it /_unsigned_/ seems to be the correct choice. /http://www.gnu.org/software/libc/manual/html_node/Attribute-Meanings.html#index-dev_005ft-1500/ *clock_t* is defined as the value returned by clock(), and the manual page states that "if the processor time used is not available or its value cannot be represented, the function returns the value (clock_t) -1." This in turn suggests that clock_t should be a _signed_ type. /http://www.gnu.org/software/libc/manual/html_node/CPU-Time.html#index-clock_005ft-2607 /As an additional reference, attached is the output generated by musl-alltypes (posted on April 18) for the above architectures. / /Best regards, Zvi --------------020008000403030000010200 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit Greetings,

The current architecture-specific type definitions (arch/*/bits/alltypes.h) seem to entail the following inconsistent signed/unsigned types:

type      x86_64        i386
-------------------------------
uid_t     unsigned      signed
gid_t     unsigned      signed
dev_t     unsigned      signed
clock_t   signed        unsigned

For uid_t and gid_t, the GNU documentation specifies _unsigned int_:
http://www.gnu.org/software/libc/manual/html_node/Reading-Persona.html#index-uid_005ft-3309

For dev_t, the specification requires _an integer type no narrower than int_: and given the value it is expected to hold (file device numbers), making it _unsigned_ seems to be the correct choice.
http://www.gnu.org/software/libc/manual/html_node/Attribute-Meanings.html#index-dev_005ft-1500

clock_t is defined as the value returned by clock(), and the manual page states that "if the processor time used is not available or its value cannot be represented, the function returns the value (clock_t) -1." This in turn suggests that clock_t should be a _signed_ type.
http://www.gnu.org/software/libc/manual/html_node/CPU-Time.html#index-clock_005ft-2607

As an additional reference, attached is the output generated by musl-alltypes (posted on April 18) for the above architectures.

Best regards,
Zvi

--------------020008000403030000010200-- --------------080801040302000301050801 Content-Type: text/plain; charset="UTF-8"; name="musl-alltypes.i386" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="musl-alltypes.i386" ICAgICAgICAgICAgICAgICAgICBuYW1lICAgICAgICAgICAgCSAgICBzaXplCSAgICAgIHNp Z25lZAogICAgICAgICAgICAgICAgICAgID09PT0gICAgICAgICAgICAJICAgID09PT0JICAg ICAgPT09PT09CiAgICAgICAgICAgICAgICAgd2NoYXJfdCAgICAgICAgICAgIAkgICAgICAg NAkgICAgICBzaWduZWQKCiAgICAgICAgICAgICAgICAgIHNpemVfdCAgICAgICAgICAgIAkg ICAgICAgNAkgICAgdW5zaWduZWQKICAgICAgICAgICAgICAgICBzc2l6ZV90ICAgICAgICAg ICAgCSAgICAgICA0CSAgICAgIHNpZ25lZAogICAgICAgICAgICAgICBwdHJkaWZmX3QgICAg ICAgICAgICAJICAgICAgIDQJICAgICAgc2lnbmVkCgogICAgICAgICAgICAgICAgICB3aW50 X3QgICAgICAgICAgICAJICAgICAgIDQJICAgICAgc2lnbmVkCiAgICAgICAgICAgICAgIHdj dHJhbnNfdCAgICAgICAgICAgIAkgICAgICAgNAkgICAgdW5zaWduZWQKICAgICAgICAgICAg ICAgIHdjdHlwZV90ICAgICAgICAgICAgCSAgICAgICA0CSAgICB1bnNpZ25lZAoKICAgICAg ICAgICAgICAgICAgaW50OF90ICAgICAgICAgICAgCSAgICAgICAxCSAgICAgIHNpZ25lZAog ICAgICAgICAgICAgICAgIGludDE2X3QgICAgICAgICAgICAJICAgICAgIDIJICAgICAgc2ln bmVkCiAgICAgICAgICAgICAgICAgaW50MzJfdCAgICAgICAgICAgIAkgICAgICAgNAkgICAg ICBzaWduZWQKICAgICAgICAgICAgICAgICBpbnQ2NF90ICAgICAgICAgICAgCSAgICAgICA4 CSAgICAgIHNpZ25lZAoKICAgICAgICAgICAgICAgICB1aW50OF90ICAgICAgICAgICAgCSAg ICAgICAxCSAgICB1bnNpZ25lZAogICAgICAgICAgICAgICAgdWludDE2X3QgICAgICAgICAg ICAJICAgICAgIDIJICAgIHVuc2lnbmVkCiAgICAgICAgICAgICAgICB1aW50MzJfdCAgICAg ICAgICAgIAkgICAgICAgNAkgICAgdW5zaWduZWQKICAgICAgICAgICAgICAgIHVpbnQ2NF90 ICAgICAgICAgICAgCSAgICAgICA4CSAgICB1bnNpZ25lZAoKICAgICAgICAgICAgICBfX3Vp bnQxNl90ICAgICAgICAgICAgCSAgICAgICAyCSAgICB1bnNpZ25lZAogICAgICAgICAgICAg IF9fdWludDMyX3QgICAgICAgICAgICAJICAgICAgIDQJICAgIHVuc2lnbmVkCiAgICAgICAg ICAgICAgX191aW50NjRfdCAgICAgICAgICAgIAkgICAgICAgOAkgICAgdW5zaWduZWQKCiAg ICAgICAgICAgICBpbnRfZmFzdDhfdCAgICAgICAgICAgIAkgICAgICAgMQkgICAgICBzaWdu ZWQKICAgICAgICAgICAgaW50X2Zhc3QxNl90ICAgICAgICAgICAgCSAgICAgICA0CSAgICAg IHNpZ25lZAogICAgICAgICAgICBpbnRfZmFzdDMyX3QgICAgICAgICAgICAJICAgICAgIDQJ ICAgICAgc2lnbmVkCiAgICAgICAgICAgIGludF9mYXN0NjRfdCAgICAgICAgICAgIAkgICAg ICAgOAkgICAgICBzaWduZWQKCiAgICAgICAgICAgIHVpbnRfZmFzdDhfdCAgICAgICAgICAg IAkgICAgICAgMQkgICAgdW5zaWduZWQKICAgICAgICAgICB1aW50X2Zhc3QxNl90ICAgICAg ICAgICAgCSAgICAgICA0CSAgICB1bnNpZ25lZAogICAgICAgICAgIHVpbnRfZmFzdDMyX3Qg ICAgICAgICAgICAJICAgICAgIDQJICAgIHVuc2lnbmVkCiAgICAgICAgICAgdWludF9mYXN0 NjRfdCAgICAgICAgICAgIAkgICAgICAgOAkgICAgdW5zaWduZWQKCiAgICAgICAgICAgICAg ICBpbnRwdHJfdCAgICAgICAgICAgIAkgICAgICAgNAkgICAgICBzaWduZWQKICAgICAgICAg ICAgICAgdWludHB0cl90ICAgICAgICAgICAgCSAgICAgICA0CSAgICB1bnNpZ25lZAoKICAg ICAgICAgICAgICAgIGludG1heF90ICAgICAgICAgICAgCSAgICAgICA4CSAgICAgIHNpZ25l ZAogICAgICAgICAgICAgICB1aW50bWF4X3QgICAgICAgICAgICAJICAgICAgIDgJICAgIHVu c2lnbmVkCgogICAgICAgICAgICAgICAgIGZsb2F0X3QgICAgICAgICAgICAJICAgICAgMTIJ ICAgICAgc2lnbmVkCiAgICAgICAgICAgICAgICBkb3VibGVfdCAgICAgICAgICAgIAkgICAg ICAxMgkgICAgICBzaWduZWQKCiAgICAgICAgICAgICAgICAgIHRpbWVfdCAgICAgICAgICAg IAkgICAgICAgNAkgICAgICBzaWduZWQKICAgICAgICAgICAgICB1c2Vjb25kc190ICAgICAg ICAgICAgCSAgICAgICA0CSAgICB1bnNpZ25lZAogICAgICAgICAgICAgc3VzZWNvbmRzX3Qg ICAgICAgICAgICAJICAgICAgIDQJICAgICAgc2lnbmVkCgogICAgICAgICAgICAgICAgIHZh X2xpc3QgICAgICAgICAgICAJICAgICAgIDQJICAgICAgICAgICAgCgogICAgICAgICAgICAg ICAgIHRpbWV2YWwgICAgICAgICAgICAJICAgICAgIDgJICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgdGltZXZhbC50dl9zZWMgICAgIAkgICAgICAgNAkgICAgICBzaWduZWQKICAg ICAgICAgICAgICAgICB0aW1ldmFsLnR2X3VzZWMgICAgCSAgICAgICA0CSAgICAgIHNpZ25l ZAoKICAgICAgICAgICAgICAgIHRpbWVzcGVjICAgICAgICAgICAgCSAgICAgICA4CSAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgdGltZXNwZWMudHZfc2VjICAgICAJICAgICAgIDQJ ICAgICAgc2lnbmVkCiAgICAgICAgICAgICAgICB0aW1lc3BlYy50dl9uc2VjICAgIAkgICAg ICAgNAkgICAgICBzaWduZWQKCiAgICAgICAgICAgICAgICAgICBwaWRfdCAgICAgICAgICAg IAkgICAgICAgNAkgICAgICBzaWduZWQKICAgICAgICAgICAgICAgICAgICBpZF90ICAgICAg ICAgICAgCSAgICAgICA0CSAgICAgIHNpZ25lZAogICAgICAgICAgICAgICAgICAgdWlkX3Qg ICAgICAgICAgICAJICAgICAgIDQJICAgICAgc2lnbmVkCiAgICAgICAgICAgICAgICAgICBn aWRfdCAgICAgICAgICAgIAkgICAgICAgNAkgICAgICBzaWduZWQKICAgICAgICAgICAgICAg ICAgIGtleV90ICAgICAgICAgICAgCSAgICAgICA0CSAgICAgIHNpZ25lZAoKICAgICAgICAg ICAgICAgcHRocmVhZF90ICAgICAgICAgICAgCSAgICAgICA0CSAgICAgICAgICAgIAoKICAg ICAgICAgIHB0aHJlYWRfb25jZV90ICAgICAgICAgICAgCSAgICAgICA0CSAgICAgIHNpZ25l ZAogICAgICAgICAgIHB0aHJlYWRfa2V5X3QgICAgICAgICAgICAJICAgICAgIDQJICAgICAg c2lnbmVkCiAgICAgIHB0aHJlYWRfc3BpbmxvY2tfdCAgICAgICAgICAgIAkgICAgICAgNAkg ICAgICBzaWduZWQKCiAgICAgICAgICBwdGhyZWFkX2F0dHJfdCAgICAgICAgICAgIAkgICAg ICAzNgkgICAgICAgICAgICAKICAgICAgICAgIHB0aHJlYWRfYXR0cl90Ll9fdS5fX2lbMF0g CSAgICAgICA0CSAgICAgIHNpZ25lZAogICAgICAgICAgcHRocmVhZF9hdHRyX3QuX191Ll9f c1swXSAJICAgICAgIDQJICAgICAgc2lnbmVkCgogICAgIHB0aHJlYWRfbXV0ZXhhdHRyX3Qg ICAgICAgICAgICAJICAgICAgIDQJICAgIHVuc2lnbmVkCiAgICAgIHB0aHJlYWRfY29uZGF0 dHJfdCAgICAgICAgICAgIAkgICAgICAgNAkgICAgdW5zaWduZWQKICAgcHRocmVhZF9iYXJy aWVyYXR0cl90ICAgICAgICAgICAgCSAgICAgICA0CSAgICB1bnNpZ25lZAoKICAgIHB0aHJl YWRfcndsb2NrYXR0cl90ICAgICAgICAgICAgCSAgICAgICA4CSAgICAgICAgICAgIAogICAg cHRocmVhZF9yd2xvY2thdHRyX3QuX19hdHRyWzBdICAJICAgICAgIDQJICAgICAgc2lnbmVk CgogICAgICAgICBwdGhyZWFkX211dGV4X3QgICAgICAgICAgICAJICAgICAgMjQJICAgICAg ICAgICAgCiAgICAgICAgIHB0aHJlYWRfbXV0ZXhfdC5fX3UuX19pWzBdIAkgICAgICAgNAkg ICAgICBzaWduZWQKICAgICAgICAgcHRocmVhZF9tdXRleF90Ll9fdS5fX3BbMF0gCSAgICAg ICA0CSAgICB1bnNpZ25lZAoKICAgICAgICAgIHB0aHJlYWRfY29uZF90ICAgICAgICAgICAg CSAgICAgIDQ4CSAgICAgICAgICAgIAogICAgICAgICAgcHRocmVhZF9jb25kX3QuX191Ll9f aVswXSAJICAgICAgIDQJICAgICAgc2lnbmVkCiAgICAgICAgICBwdGhyZWFkX2NvbmRfdC5f X3UuX19wWzBdIAkgICAgICAgNAkgICAgdW5zaWduZWQKCiAgICAgICBwdGhyZWFkX2JhcnJp ZXJfdCAgICAgICAgICAgIAkgICAgICAyMAkgICAgICAgICAgICAKICAgICAgIHB0aHJlYWRf YmFycmllcl90Ll9fdS5fX2lbMF0gCSAgICAgICA0CSAgICAgIHNpZ25lZAogICAgICAgcHRo cmVhZF9iYXJyaWVyX3QuX191Ll9fcFswXSAJICAgICAgIDQJICAgIHVuc2lnbmVkCgogICAg ICAgIHB0aHJlYWRfcndsb2NrX3QgICAgICAgICAgICAJICAgICAgMzIJICAgICAgICAgICAg CiAgICAgICAgcHRocmVhZF9yd2xvY2tfdC5fX3UuX19pWzBdIAkgICAgICAgNAkgICAgICBz aWduZWQKICAgICAgICBwdGhyZWFkX3J3bG9ja190Ll9fdS5fX3BbMF0gCSAgICAgICA0CSAg ICB1bnNpZ25lZAoKICAgICAgICAgICAgICAgICAgIG9mZl90ICAgICAgICAgICAgCSAgICAg ICA4CSAgICAgIHNpZ25lZAogICAgICAgICAgICAgICAgICBtb2RlX3QgICAgICAgICAgICAJ ICAgICAgIDQJICAgIHVuc2lnbmVkCiAgICAgICAgICAgICAgICAgbmxpbmtfdCAgICAgICAg ICAgIAkgICAgICAgNAkgICAgdW5zaWduZWQKICAgICAgICAgICAgICAgICAgIGlub190ICAg ICAgICAgICAgCSAgICAgICA4CSAgICB1bnNpZ25lZAogICAgICAgICAgICAgICAgICAgZGV2 X3QgICAgICAgICAgICAJICAgICAgIDgJICAgICAgc2lnbmVkCiAgICAgICAgICAgICAgIGJs a3NpemVfdCAgICAgICAgICAgIAkgICAgICAgNAkgICAgICBzaWduZWQKICAgICAgICAgICAg ICAgIGJsa2NudF90ICAgICAgICAgICAgCSAgICAgICA4CSAgICAgIHNpZ25lZAogICAgICAg ICAgICAgIGZzYmxrY250X3QgICAgICAgICAgICAJICAgICAgIDgJICAgIHVuc2lnbmVkCiAg ICAgICAgICAgICAgZnNmaWxjbnRfdCAgICAgICAgICAgIAkgICAgICAgOAkgICAgdW5zaWdu ZWQKCiAgICAgICAgICAgICAgICAgdGltZXJfdCAgICAgICAgICAgIAkgICAgICAgNAkgICAg dW5zaWduZWQKICAgICAgICAgICAgICAgY2xvY2tpZF90ICAgICAgICAgICAgCSAgICAgICA0 CSAgICAgIHNpZ25lZAogICAgICAgICAgICAgICAgIGNsb2NrX3QgICAgICAgICAgICAJICAg ICAgIDQJICAgIHVuc2lnbmVkCgogICAgICAgICAgICAgICAgc2lnc2V0X3QgICAgICAgICAg ICAJICAgICAxMjgJICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBzaWdzZXRfdC5fX2Jp dHM6ICAgIAkgICAgICAzMgkgIGFycmF5LXNpemUKICAgICAgICAgICAgICAgIHNpZ3NldF90 Ll9fYml0c1swXSAgCSAgICAgICA0CSAgICAgIHNpZ25lZAoKICAgICAgICAgICAgICAgc2ln aW5mb190ICAgICAgICAgICAgCSAgICAgMTI4CSAgICAgICAgICAgIAoKICAgICAgICAgICAg ICAgc29ja2xlbl90ICAgICAgICAgICAgCSAgICAgICA0CSAgICB1bnNpZ25lZAogICAgICAg ICAgICAgc2FfZmFtaWx5X3QgICAgICAgICAgICAJICAgICAgIDIJICAgIHVuc2lnbmVkCiAg ICAgICAgICAgICAgIGluX3BvcnRfdCAgICAgICAgICAgIAkgICAgICAgMgkgICAgdW5zaWdu ZWQKICAgICAgICAgICAgICAgaW5fYWRkcl90ICAgICAgICAgICAgCSAgICAgICA0CSAgICB1 bnNpZ25lZAoKICAgICAgICAgICAgICAgICBpbl9hZGRyICAgICAgICAgICAgCSAgICAgICA0 CSAgICAgICAgICAgIAogICAgICAgICAgICAgICAgIGluX2FkZHIuc19hZGRyICAgICAJICAg ICAgIDQJICAgICAgc2lnbmVkCgogICAgICAgICAgICAgICAgIG5sX2l0ZW0gICAgICAgICAg ICAJICAgICAgIDQJICAgICAgc2lnbmVkCgogICAgICAgICAgICAgICAgICAgaW92ZWMgICAg ICAgICAgICAJICAgICAgIDgJICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICBpb3Zl Yy5pb3ZfYmFzZSAgIAkgICAgICAgNAkgICAgdW5zaWduZWQKICAgICAgICAgICAgICAgICAg IGlvdmVjLmlvdl9sZW4gICAgCSAgICAgICA0CSAgICAgIHNpZ25lZAoKCg== --------------080801040302000301050801 Content-Type: text/plain; charset="UTF-8"; name="musl-alltypes.x86_64" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="musl-alltypes.x86_64" ICAgICAgICAgICAgICAgICAgICBuYW1lICAgICAgICAgICAgCSAgICBzaXplCSAgICAgIHNp Z25lZAogICAgICAgICAgICAgICAgICAgID09PT0gICAgICAgICAgICAJICAgID09PT0JICAg ICAgPT09PT09CiAgICAgICAgICAgICAgICAgd2NoYXJfdCAgICAgICAgICAgIAkgICAgICAg NAkgICAgICBzaWduZWQKCiAgICAgICAgICAgICAgICAgIHNpemVfdCAgICAgICAgICAgIAkg ICAgICAgOAkgICAgdW5zaWduZWQKICAgICAgICAgICAgICAgICBzc2l6ZV90ICAgICAgICAg ICAgCSAgICAgICA4CSAgICAgIHNpZ25lZAogICAgICAgICAgICAgICBwdHJkaWZmX3QgICAg ICAgICAgICAJICAgICAgIDgJICAgICAgc2lnbmVkCgogICAgICAgICAgICAgICAgICB3aW50 X3QgICAgICAgICAgICAJICAgICAgIDQJICAgICAgc2lnbmVkCiAgICAgICAgICAgICAgIHdj dHJhbnNfdCAgICAgICAgICAgIAkgICAgICAgOAkgICAgdW5zaWduZWQKICAgICAgICAgICAg ICAgIHdjdHlwZV90ICAgICAgICAgICAgCSAgICAgICA4CSAgICB1bnNpZ25lZAoKICAgICAg ICAgICAgICAgICAgaW50OF90ICAgICAgICAgICAgCSAgICAgICAxCSAgICAgIHNpZ25lZAog ICAgICAgICAgICAgICAgIGludDE2X3QgICAgICAgICAgICAJICAgICAgIDIJICAgICAgc2ln bmVkCiAgICAgICAgICAgICAgICAgaW50MzJfdCAgICAgICAgICAgIAkgICAgICAgNAkgICAg ICBzaWduZWQKICAgICAgICAgICAgICAgICBpbnQ2NF90ICAgICAgICAgICAgCSAgICAgICA4 CSAgICAgIHNpZ25lZAoKICAgICAgICAgICAgICAgICB1aW50OF90ICAgICAgICAgICAgCSAg ICAgICAxCSAgICB1bnNpZ25lZAogICAgICAgICAgICAgICAgdWludDE2X3QgICAgICAgICAg ICAJICAgICAgIDIJICAgIHVuc2lnbmVkCiAgICAgICAgICAgICAgICB1aW50MzJfdCAgICAg ICAgICAgIAkgICAgICAgNAkgICAgdW5zaWduZWQKICAgICAgICAgICAgICAgIHVpbnQ2NF90 ICAgICAgICAgICAgCSAgICAgICA4CSAgICB1bnNpZ25lZAoKICAgICAgICAgICAgICBfX3Vp bnQxNl90ICAgICAgICAgICAgCSAgICAgICAyCSAgICB1bnNpZ25lZAogICAgICAgICAgICAg IF9fdWludDMyX3QgICAgICAgICAgICAJICAgICAgIDQJICAgIHVuc2lnbmVkCiAgICAgICAg ICAgICAgX191aW50NjRfdCAgICAgICAgICAgIAkgICAgICAgOAkgICAgdW5zaWduZWQKCiAg ICAgICAgICAgICBpbnRfZmFzdDhfdCAgICAgICAgICAgIAkgICAgICAgMQkgICAgICBzaWdu ZWQKICAgICAgICAgICAgaW50X2Zhc3QxNl90ICAgICAgICAgICAgCSAgICAgICA0CSAgICAg IHNpZ25lZAogICAgICAgICAgICBpbnRfZmFzdDMyX3QgICAgICAgICAgICAJICAgICAgIDQJ ICAgICAgc2lnbmVkCiAgICAgICAgICAgIGludF9mYXN0NjRfdCAgICAgICAgICAgIAkgICAg ICAgOAkgICAgICBzaWduZWQKCiAgICAgICAgICAgIHVpbnRfZmFzdDhfdCAgICAgICAgICAg IAkgICAgICAgMQkgICAgdW5zaWduZWQKICAgICAgICAgICB1aW50X2Zhc3QxNl90ICAgICAg ICAgICAgCSAgICAgICA0CSAgICB1bnNpZ25lZAogICAgICAgICAgIHVpbnRfZmFzdDMyX3Qg ICAgICAgICAgICAJICAgICAgIDQJICAgIHVuc2lnbmVkCiAgICAgICAgICAgdWludF9mYXN0 NjRfdCAgICAgICAgICAgIAkgICAgICAgOAkgICAgdW5zaWduZWQKCiAgICAgICAgICAgICAg ICBpbnRwdHJfdCAgICAgICAgICAgIAkgICAgICAgOAkgICAgICBzaWduZWQKICAgICAgICAg ICAgICAgdWludHB0cl90ICAgICAgICAgICAgCSAgICAgICA4CSAgICB1bnNpZ25lZAoKICAg ICAgICAgICAgICAgIGludG1heF90ICAgICAgICAgICAgCSAgICAgICA4CSAgICAgIHNpZ25l ZAogICAgICAgICAgICAgICB1aW50bWF4X3QgICAgICAgICAgICAJICAgICAgIDgJICAgIHVu c2lnbmVkCgogICAgICAgICAgICAgICAgIGZsb2F0X3QgICAgICAgICAgICAJICAgICAgIDQJ ICAgICAgc2lnbmVkCiAgICAgICAgICAgICAgICBkb3VibGVfdCAgICAgICAgICAgIAkgICAg ICAgOAkgICAgICBzaWduZWQKCiAgICAgICAgICAgICAgICAgIHRpbWVfdCAgICAgICAgICAg IAkgICAgICAgOAkgICAgICBzaWduZWQKICAgICAgICAgICAgICB1c2Vjb25kc190ICAgICAg ICAgICAgCSAgICAgICA0CSAgICB1bnNpZ25lZAogICAgICAgICAgICAgc3VzZWNvbmRzX3Qg ICAgICAgICAgICAJICAgICAgIDgJICAgICAgc2lnbmVkCgogICAgICAgICAgICAgICAgIHZh X2xpc3QgICAgICAgICAgICAJICAgICAgMjQJICAgICAgICAgICAgCgogICAgICAgICAgICAg ICAgIHRpbWV2YWwgICAgICAgICAgICAJICAgICAgMTYJICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgdGltZXZhbC50dl9zZWMgICAgIAkgICAgICAgOAkgICAgICBzaWduZWQKICAg ICAgICAgICAgICAgICB0aW1ldmFsLnR2X3VzZWMgICAgCSAgICAgICA4CSAgICAgIHNpZ25l ZAoKICAgICAgICAgICAgICAgIHRpbWVzcGVjICAgICAgICAgICAgCSAgICAgIDE2CSAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgdGltZXNwZWMudHZfc2VjICAgICAJICAgICAgIDgJ ICAgICAgc2lnbmVkCiAgICAgICAgICAgICAgICB0aW1lc3BlYy50dl9uc2VjICAgIAkgICAg ICAgOAkgICAgICBzaWduZWQKCiAgICAgICAgICAgICAgICAgICBwaWRfdCAgICAgICAgICAg IAkgICAgICAgNAkgICAgICBzaWduZWQKICAgICAgICAgICAgICAgICAgICBpZF90ICAgICAg ICAgICAgCSAgICAgICA0CSAgICAgIHNpZ25lZAogICAgICAgICAgICAgICAgICAgdWlkX3Qg ICAgICAgICAgICAJICAgICAgIDQJICAgIHVuc2lnbmVkCiAgICAgICAgICAgICAgICAgICBn aWRfdCAgICAgICAgICAgIAkgICAgICAgNAkgICAgdW5zaWduZWQKICAgICAgICAgICAgICAg ICAgIGtleV90ICAgICAgICAgICAgCSAgICAgICA0CSAgICAgIHNpZ25lZAoKICAgICAgICAg ICAgICAgcHRocmVhZF90ICAgICAgICAgICAgCSAgICAgICA4CSAgICAgICAgICAgIAoKICAg ICAgICAgIHB0aHJlYWRfb25jZV90ICAgICAgICAgICAgCSAgICAgICA0CSAgICAgIHNpZ25l ZAogICAgICAgICAgIHB0aHJlYWRfa2V5X3QgICAgICAgICAgICAJICAgICAgIDQJICAgICAg c2lnbmVkCiAgICAgIHB0aHJlYWRfc3BpbmxvY2tfdCAgICAgICAgICAgIAkgICAgICAgNAkg ICAgICBzaWduZWQKCiAgICAgICAgICBwdGhyZWFkX2F0dHJfdCAgICAgICAgICAgIAkgICAg ICA1NgkgICAgICAgICAgICAKICAgICAgICAgIHB0aHJlYWRfYXR0cl90Ll9fdS5fX2lbMF0g CSAgICAgICA0CSAgICAgIHNpZ25lZAogICAgICAgICAgcHRocmVhZF9hdHRyX3QuX191Ll9f c1swXSAJICAgICAgIDgJICAgICAgc2lnbmVkCgogICAgIHB0aHJlYWRfbXV0ZXhhdHRyX3Qg ICAgICAgICAgICAJICAgICAgIDQJICAgIHVuc2lnbmVkCiAgICAgIHB0aHJlYWRfY29uZGF0 dHJfdCAgICAgICAgICAgIAkgICAgICAgNAkgICAgdW5zaWduZWQKICAgcHRocmVhZF9iYXJy aWVyYXR0cl90ICAgICAgICAgICAgCSAgICAgICA0CSAgICB1bnNpZ25lZAoKICAgIHB0aHJl YWRfcndsb2NrYXR0cl90ICAgICAgICAgICAgCSAgICAgICA4CSAgICAgICAgICAgIAogICAg cHRocmVhZF9yd2xvY2thdHRyX3QuX19hdHRyWzBdICAJICAgICAgIDQJICAgICAgc2lnbmVk CgogICAgICAgICBwdGhyZWFkX211dGV4X3QgICAgICAgICAgICAJICAgICAgNDAJICAgICAg ICAgICAgCiAgICAgICAgIHB0aHJlYWRfbXV0ZXhfdC5fX3UuX19pWzBdIAkgICAgICAgNAkg ICAgICBzaWduZWQKICAgICAgICAgcHRocmVhZF9tdXRleF90Ll9fdS5fX3BbMF0gCSAgICAg ICA4CSAgICB1bnNpZ25lZAoKICAgICAgICAgIHB0aHJlYWRfY29uZF90ICAgICAgICAgICAg CSAgICAgIDQ4CSAgICAgICAgICAgIAogICAgICAgICAgcHRocmVhZF9jb25kX3QuX191Ll9f aVswXSAJICAgICAgIDQJICAgICAgc2lnbmVkCiAgICAgICAgICBwdGhyZWFkX2NvbmRfdC5f X3UuX19wWzBdIAkgICAgICAgOAkgICAgdW5zaWduZWQKCiAgICAgICBwdGhyZWFkX2JhcnJp ZXJfdCAgICAgICAgICAgIAkgICAgICAzMgkgICAgICAgICAgICAKICAgICAgIHB0aHJlYWRf YmFycmllcl90Ll9fdS5fX2lbMF0gCSAgICAgICA0CSAgICAgIHNpZ25lZAogICAgICAgcHRo cmVhZF9iYXJyaWVyX3QuX191Ll9fcFswXSAJICAgICAgIDgJICAgIHVuc2lnbmVkCgogICAg ICAgIHB0aHJlYWRfcndsb2NrX3QgICAgICAgICAgICAJICAgICAgNTYJICAgICAgICAgICAg CiAgICAgICAgcHRocmVhZF9yd2xvY2tfdC5fX3UuX19pWzBdIAkgICAgICAgNAkgICAgICBz aWduZWQKICAgICAgICBwdGhyZWFkX3J3bG9ja190Ll9fdS5fX3BbMF0gCSAgICAgICA4CSAg ICB1bnNpZ25lZAoKICAgICAgICAgICAgICAgICAgIG9mZl90ICAgICAgICAgICAgCSAgICAg ICA4CSAgICAgIHNpZ25lZAogICAgICAgICAgICAgICAgICBtb2RlX3QgICAgICAgICAgICAJ ICAgICAgIDQJICAgIHVuc2lnbmVkCiAgICAgICAgICAgICAgICAgbmxpbmtfdCAgICAgICAg ICAgIAkgICAgICAgOAkgICAgdW5zaWduZWQKICAgICAgICAgICAgICAgICAgIGlub190ICAg ICAgICAgICAgCSAgICAgICA4CSAgICB1bnNpZ25lZAogICAgICAgICAgICAgICAgICAgZGV2 X3QgICAgICAgICAgICAJICAgICAgIDgJICAgIHVuc2lnbmVkCiAgICAgICAgICAgICAgIGJs a3NpemVfdCAgICAgICAgICAgIAkgICAgICAgOAkgICAgICBzaWduZWQKICAgICAgICAgICAg ICAgIGJsa2NudF90ICAgICAgICAgICAgCSAgICAgICA4CSAgICAgIHNpZ25lZAogICAgICAg ICAgICAgIGZzYmxrY250X3QgICAgICAgICAgICAJICAgICAgIDgJICAgIHVuc2lnbmVkCiAg ICAgICAgICAgICAgZnNmaWxjbnRfdCAgICAgICAgICAgIAkgICAgICAgOAkgICAgdW5zaWdu ZWQKCiAgICAgICAgICAgICAgICAgdGltZXJfdCAgICAgICAgICAgIAkgICAgICAgOAkgICAg dW5zaWduZWQKICAgICAgICAgICAgICAgY2xvY2tpZF90ICAgICAgICAgICAgCSAgICAgICA0 CSAgICAgIHNpZ25lZAogICAgICAgICAgICAgICAgIGNsb2NrX3QgICAgICAgICAgICAJICAg ICAgIDgJICAgICAgc2lnbmVkCgogICAgICAgICAgICAgICAgc2lnc2V0X3QgICAgICAgICAg ICAJICAgICAxMjgJICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBzaWdzZXRfdC5fX2Jp dHM6ICAgIAkgICAgICAxNgkgIGFycmF5LXNpemUKICAgICAgICAgICAgICAgIHNpZ3NldF90 Ll9fYml0c1swXSAgCSAgICAgICA4CSAgICAgIHNpZ25lZAoKICAgICAgICAgICAgICAgc2ln aW5mb190ICAgICAgICAgICAgCSAgICAgMTI4CSAgICAgICAgICAgIAoKICAgICAgICAgICAg ICAgc29ja2xlbl90ICAgICAgICAgICAgCSAgICAgICA0CSAgICB1bnNpZ25lZAogICAgICAg ICAgICAgc2FfZmFtaWx5X3QgICAgICAgICAgICAJICAgICAgIDIJICAgIHVuc2lnbmVkCiAg ICAgICAgICAgICAgIGluX3BvcnRfdCAgICAgICAgICAgIAkgICAgICAgMgkgICAgdW5zaWdu ZWQKICAgICAgICAgICAgICAgaW5fYWRkcl90ICAgICAgICAgICAgCSAgICAgICA0CSAgICB1 bnNpZ25lZAoKICAgICAgICAgICAgICAgICBpbl9hZGRyICAgICAgICAgICAgCSAgICAgICA0 CSAgICAgICAgICAgIAogICAgICAgICAgICAgICAgIGluX2FkZHIuc19hZGRyICAgICAJICAg ICAgIDQJICAgICAgc2lnbmVkCgogICAgICAgICAgICAgICAgIG5sX2l0ZW0gICAgICAgICAg ICAJICAgICAgIDQJICAgICAgc2lnbmVkCgogICAgICAgICAgICAgICAgICAgaW92ZWMgICAg ICAgICAgICAJICAgICAgMTYJICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICBpb3Zl Yy5pb3ZfYmFzZSAgIAkgICAgICAgOAkgICAgdW5zaWduZWQKICAgICAgICAgICAgICAgICAg IGlvdmVjLmlvdl9sZW4gICAgCSAgICAgICA4CSAgICAgIHNpZ25lZAoKCg== --------------080801040302000301050801-- From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3271 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: sign (in)consistency between architectures Date: Wed, 1 May 2013 20:00:15 +0200 Message-ID: <20130501180015.GN12689@port70.net> References: <51814B3F.4040005@eservices.virginia.edu> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1367431232 21361 80.91.229.3 (1 May 2013 18:00:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 May 2013 18:00:32 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3275-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 01 20:00:32 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UXbKN-0001aY-UA for gllmg-musl@plane.gmane.org; Wed, 01 May 2013 20:00:28 +0200 Original-Received: (qmail 13915 invoked by uid 550); 1 May 2013 18:00:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 13907 invoked from network); 1 May 2013 18:00:27 -0000 Content-Disposition: inline In-Reply-To: <51814B3F.4040005@eservices.virginia.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3271 Archived-At: * Z. Gilboa [2013-05-01 13:05:03 -0400]: > The current architecture-specific type definitions > (arch/*/bits/alltypes.h) seem to entail the following inconsistent > signed/unsigned types: > > type x86_64 i386 > ------------------------------- > uid_t unsigned signed > gid_t unsigned signed > dev_t unsigned signed > clock_t signed unsigned i can verify that glibc uses unsigned uid_t,gid_t,dev_t and signed clock_t of course applications should not depend on the signedness, but if they appear in a c++ api then the difference can cause problems and cock_t may be used in arithmetics where signedness matters From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3272 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: sign (in)consistency between architectures Date: Wed, 1 May 2013 16:00:07 -0400 Message-ID: <20130501200007.GM20323@brightrain.aerifal.cx> References: <51814B3F.4040005@eservices.virginia.edu> <20130501180015.GN12689@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1367438426 31825 80.91.229.3 (1 May 2013 20:00:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 May 2013 20:00:26 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3276-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 01 22:00:27 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UXdCS-0001h6-Km for gllmg-musl@plane.gmane.org; Wed, 01 May 2013 22:00:24 +0200 Original-Received: (qmail 22198 invoked by uid 550); 1 May 2013 20:00:22 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 22190 invoked from network); 1 May 2013 20:00:21 -0000 Content-Disposition: inline In-Reply-To: <20130501180015.GN12689@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3272 Archived-At: On Wed, May 01, 2013 at 08:00:15PM +0200, Szabolcs Nagy wrote: > * Z. Gilboa [2013-05-01 13:05:03 -0400]: > > The current architecture-specific type definitions > > (arch/*/bits/alltypes.h) seem to entail the following inconsistent > > signed/unsigned types: > > > > type x86_64 i386 > > ------------------------------- > > uid_t unsigned signed > > gid_t unsigned signed > > dev_t unsigned signed > > clock_t signed unsigned > > > i can verify that glibc uses unsigned > uid_t,gid_t,dev_t and signed clock_t > > of course applications should not depend on > the signedness, but if they appear in a c++ > api then the difference can cause problems > > and cock_t may be used in arithmetics where > signedness matters uid_t, gid_t, and dev_t we can consider changing; I don't think it matters a whole lot and like you said they affect C++ ABI. clock_t cannot be changed without making the clock() function unusable. See glibc bug #13080 (WONTFIX): http://sourceware.org/bugzilla/show_bug.cgi?id=13080 Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3273 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: sign (in)consistency between architectures Date: Wed, 1 May 2013 18:41:32 -0400 Message-ID: <20130501224132.GN20323@brightrain.aerifal.cx> References: <51814B3F.4040005@eservices.virginia.edu> <20130501180015.GN12689@port70.net> <20130501200007.GM20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1367448105 1765 80.91.229.3 (1 May 2013 22:41:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 May 2013 22:41:45 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3277-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 02 00:41:46 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UXfib-00005L-KG for gllmg-musl@plane.gmane.org; Thu, 02 May 2013 00:41:45 +0200 Original-Received: (qmail 8177 invoked by uid 550); 1 May 2013 22:41:44 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 8164 invoked from network); 1 May 2013 22:41:44 -0000 Content-Disposition: inline In-Reply-To: <20130501200007.GM20323@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3273 Archived-At: On Wed, May 01, 2013 at 04:00:07PM -0400, Rich Felker wrote: > On Wed, May 01, 2013 at 08:00:15PM +0200, Szabolcs Nagy wrote: > > * Z. Gilboa [2013-05-01 13:05:03 -0400]: > > > The current architecture-specific type definitions > > > (arch/*/bits/alltypes.h) seem to entail the following inconsistent > > > signed/unsigned types: > > > > > > type x86_64 i386 > > > ------------------------------- > > > uid_t unsigned signed > > > gid_t unsigned signed > > > dev_t unsigned signed > > > clock_t signed unsigned > > > > > > i can verify that glibc uses unsigned > > uid_t,gid_t,dev_t and signed clock_t > > > > of course applications should not depend on > > the signedness, but if they appear in a c++ > > api then the difference can cause problems > > > > and cock_t may be used in arithmetics where > > signedness matters > > uid_t, gid_t, and dev_t we can consider changing; I don't think it > matters a whole lot and like you said they affect C++ ABI. clock_t > cannot be changed without making the clock() function unusable. See > glibc bug #13080 (WONTFIX): > > http://sourceware.org/bugzilla/show_bug.cgi?id=13080 I just posted a followup on this bug: from what I can tell, it's questionable whether having the return value of clock() wrap is conforming even if clock_t is an unsigned type, and definitely non-conforming if it's a signed type. As such, I see three possible solutions: 1. Leave things along and do it the way musl does it now, where subtracting (unsigned) results works. We should probably add a check to see if the return value would be equal to (clock_t)-1, and if so, either add or subtract 1, so that the caller does not interpret the return value as an error. 2. Change clock_t to a signed type, and have clock() check for overflow and permanently return -1 once the process has used more than 2147 seconds of cpu time. This seems undesirable to applications. 3. Change clock_t to long long on 32-bit targets. This would be formally incompatible with the the glibc/LSB ABI, but in practice the worst that would happen is that the register containing the upper bits would get ignored. Any opinions on the issue? Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3274 Path: news.gmane.org!not-for-mail From: "Z. Gilboa" Newsgroups: gmane.linux.lib.musl.general Subject: Re: sign (in)consistency between architectures Date: Wed, 1 May 2013 21:39:00 -0400 Message-ID: <5181C3B4.4040801@eservices.virginia.edu> References: <51814B3F.4040005@eservices.virginia.edu> <20130501180015.GN12689@port70.net> <20130501200007.GM20323@brightrain.aerifal.cx> <20130501224132.GN20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------030305000409050101010802" X-Trace: ger.gmane.org 1367458755 29597 80.91.229.3 (2 May 2013 01:39:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 May 2013 01:39:15 +0000 (UTC) To: Original-X-From: musl-return-3278-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 02 03:39:15 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UXiUM-00074j-Uq for gllmg-musl@plane.gmane.org; Thu, 02 May 2013 03:39:15 +0200 Original-Received: (qmail 25629 invoked by uid 550); 2 May 2013 01:39:14 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 25618 invoked from network); 2 May 2013 01:39:13 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 In-Reply-To: <20130501224132.GN20323@brightrain.aerifal.cx> X-Originating-IP: [71.206.170.124] Xref: news.gmane.org gmane.linux.lib.musl.general:3274 Archived-At: --------------030305000409050101010802 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Am 01.05.2013 18:41, schrieb Rich Felker: > On Wed, May 01, 2013 at 04:00:07PM -0400, Rich Felker wrote: >> On Wed, May 01, 2013 at 08:00:15PM +0200, Szabolcs Nagy wrote: >>> * Z. Gilboa [2013-05-01 13:05:03 -0400]: >>>> The current architecture-specific type definitions >>>> (arch/*/bits/alltypes.h) seem to entail the following inconsistent >>>> signed/unsigned types: >>>> >>>> type x86_64 i386 >>>> ------------------------------- >>>> uid_t unsigned signed >>>> gid_t unsigned signed >>>> dev_t unsigned signed >>>> clock_t signed unsigned >>> >>> i can verify that glibc uses unsigned >>> uid_t,gid_t,dev_t and signed clock_t >>> >>> of course applications should not depend on >>> the signedness, but if they appear in a c++ >>> api then the difference can cause problems >>> >>> and cock_t may be used in arithmetics where >>> signedness matters >> uid_t, gid_t, and dev_t we can consider changing; I don't think it >> matters a whole lot and like you said they affect C++ ABI. clock_t >> cannot be changed without making the clock() function unusable. See >> glibc bug #13080 (WONTFIX): >> >> http://sourceware.org/bugzilla/show_bug.cgi?id=13080 > I just posted a followup on this bug: from what I can tell, it's > questionable whether having the return value of clock() wrap is > conforming even if clock_t is an unsigned type, and definitely > non-conforming if it's a signed type. As such, I see three possible > solutions: > > 1. Leave things along and do it the way musl does it now, where > subtracting (unsigned) results works. We should probably add a check > to see if the return value would be equal to (clock_t)-1, and if so, > either add or subtract 1, so that the caller does not interpret the > return value as an error. > > 2. Change clock_t to a signed type, and have clock() check for > overflow and permanently return -1 once the process has used more than > 2147 seconds of cpu time. This seems undesirable to applications. > > 3. Change clock_t to long long on 32-bit targets. This would be > formally incompatible with the the glibc/LSB ABI, but in practice the > worst that would happen is that the register containing the upper bits > would get ignored. > > Any opinions on the issue? > > Rich I consider the difference in sign to be of much greater significance, and therefore would prefer option #3. Besides, with enough patience and perseverance (/der lange Marsch durch die Institutionen.../), this might actually become the glibc solution as well:) --------------030305000409050101010802 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit

Am 01.05.2013 18:41, schrieb Rich Felker:

On Wed, May 01, 2013 at 04:00:07PM -0400, Rich Felker wrote:

On Wed, May 01, 2013 at 08:00:15PM +0200, Szabolcs Nagy wrote:

* Z. Gilboa <zg7s@eservices.virginia.edu> [2013-05-01 13:05:03 -0400]:

The current architecture-specific type definitions
(arch/*/bits/alltypes.h) seem to entail the following inconsistent
signed/unsigned types:

type      x86_64        i386
-------------------------------
uid_t     unsigned      signed
gid_t     unsigned      signed
dev_t     unsigned      signed
clock_t   signed        unsigned


i can verify that glibc uses unsigned
uid_t,gid_t,dev_t and signed clock_t

of course applications should not depend on
the signedness, but if they appear in a c++
api then the difference can cause problems

and cock_t may be used in arithmetics where
signedness matters

uid_t, gid_t, and dev_t we can consider changing; I don't think it
matters a whole lot and like you said they affect C++ ABI. clock_t
cannot be changed without making the clock() function unusable. See
glibc bug #13080 (WONTFIX):

http://sourceware.org/bugzilla/show_bug.cgi?id=13080

I just posted a followup on this bug: from what I can tell, it's
questionable whether having the return value of clock() wrap is
conforming even if clock_t is an unsigned type, and definitely
non-conforming if it's a signed type. As such, I see three possible
solutions:

1. Leave things along and do it the way musl does it now, where
subtracting (unsigned) results works. We should probably add a check
to see if the return value would be equal to (clock_t)-1, and if so,
either add or subtract 1, so that the caller does not interpret the
return value as an error.

2. Change clock_t to a signed type, and have clock() check for
overflow and permanently return -1 once the process has used more than
2147 seconds of cpu time. This seems undesirable to applications.

3. Change clock_t to long long on 32-bit targets. This would be
formally incompatible with the the glibc/LSB ABI, but in practice the
worst that would happen is that the register containing the upper bits
would get ignored.

Any opinions on the issue?

Rich

I consider the difference in sign to be of much greater significance, and therefore would prefer option #3. Besides, with enough patience and perseverance (der lange Marsch durch die Institutionen...), this might actually become the glibc solution as well:)
--------------030305000409050101010802-- From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3275 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: sign (in)consistency between architectures Date: Wed, 1 May 2013 22:47:53 -0400 Message-ID: <20130502024753.GO20323@brightrain.aerifal.cx> References: <51814B3F.4040005@eservices.virginia.edu> <20130501180015.GN12689@port70.net> <20130501200007.GM20323@brightrain.aerifal.cx> <20130501224132.GN20323@brightrain.aerifal.cx> <5181C3B4.4040801@eservices.virginia.edu> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1367462888 3183 80.91.229.3 (2 May 2013 02:48:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 May 2013 02:48:08 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3279-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 02 04:48:08 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UXjZ1-0003He-3L for gllmg-musl@plane.gmane.org; Thu, 02 May 2013 04:48:07 +0200 Original-Received: (qmail 31907 invoked by uid 550); 2 May 2013 02:48:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 31896 invoked from network); 2 May 2013 02:48:05 -0000 Content-Disposition: inline In-Reply-To: <5181C3B4.4040801@eservices.virginia.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3275 Archived-At: On Wed, May 01, 2013 at 09:39:00PM -0400, Z. Gilboa wrote: > I consider the difference in sign to be of much greater > significance, and therefore would prefer option #3. Besides, with > enough patience and perseverance (/der lange Marsch durch die > Institutionen.../), this might actually become the glibc solution as > well:) Well, the current text of POSIX acknowledges in the Application Usage text that, on some implementations, the return value of clock() wraps. Moreover, it mentions wrapping after 2147 seconds, which would be the signed wrapping point, but not whether the wrapping is to INT_MIN or to 0. It's hard to say which is worse; wrapping to INT_MIN gives you UB (integer overflow) when you subtract INT_MIN-INT_MAX, but in the real world you probably get the value you wanted, 1. Wrapping to 0 on the other hand would give you a gigantic difference when the clock wraps. Still, I see no acknowledgement that it might wrap in the ISO C definition for clock(), so it's possible that an interpretation would declare the wrapping non-conforming. In any case, I think all of these issues are good arguments that nobodu should ever use clock_t or the clock() function... Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3276 Path: news.gmane.org!not-for-mail From: Jens Gustedt Newsgroups: gmane.linux.lib.musl.general Subject: Re: sign (in)consistency between architectures Date: Thu, 02 May 2013 10:12:39 +0200 Message-ID: <1367482359.28119.118.camel@eris.loria.fr> References: <51814B3F.4040005@eservices.virginia.edu> <20130501180015.GN12689@port70.net> <20130501200007.GM20323@brightrain.aerifal.cx> <20130501224132.GN20323@brightrain.aerifal.cx> <5181C3B4.4040801@eservices.virginia.edu> <20130502024753.GO20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-10x4I/XvLb9qCzw1NUsO" X-Trace: ger.gmane.org 1367482381 9118 80.91.229.3 (2 May 2013 08:13:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 May 2013 08:13:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3280-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 02 10:13:01 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UXodQ-0007YK-UB for gllmg-musl@plane.gmane.org; Thu, 02 May 2013 10:13:01 +0200 Original-Received: (qmail 13764 invoked by uid 550); 2 May 2013 08:12:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 13755 invoked from network); 2 May 2013 08:12:58 -0000 X-IronPort-AV: E=Sophos;i="4.87,595,1363129200"; d="scan'";a="15751221" In-Reply-To: <20130502024753.GO20323@brightrain.aerifal.cx> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAABHNCSVQICAgIfAhkiAAAEb9JREFUaN7VmXuQ3lV5xz/n/O7v7333fffdW3azSTY3Qi6wGy4aEc0qWlGhWcAq7WiDrWNpO61paS29EpzWaevYpvfL2JK0VRBbBxQtg0U2BRGKhIAI4ZKwSTbZ+3u//G7nnP7BtGM7UyVAnfb56/xznuf7nXnOnOf5fuH/eYjXI8mDn/5k8ch90xNj+eKka8xkI1MTGmY6Rk/XpD5w091fPvnf7xz8sQ/sLTQ6k54SY2mW1mQY3DVX8Kdv/PvPnfyBE7hn797bxBPP3NBv28RAqgyzJqNgJIs5q7bhHW+94Yd+5/fuBrjj5l/cs/LUs/vNiVMTo5aNJQX9lks3iaivHqlt/9D7xs778Y/Uf6AE/uWa6x7wT52ZTDyLKEkoOHmW4oSaSDFxQmq7tHPuDJ5TUkv10iAGgSLvediZotf16HS6KG1RuXDT/g99/vO3vtLa8vUgELuCVAja0mVJKRaylGbgYnwP27bImYRcozkmKrWS53vYjosfhNSUIjXQUoq2K0ksRdZqTZ5Lbfs/Dl/66E/uSebmb8hF8URab48JS+IPDVJtto9uuHj8wKW//6lD/1OSznxtLEPRv2kdPH2MSBpkqlDGkLoOIgGkIWcEiTYsk1JSDpGUFAAcBzfRCKXxV+ql7/XWnn7uxcm3vOGS2rrR1UcLV+6pC4B//tjPjGdHjhwttFOEcMmMAgFeLkezWsOTkmigfyYZGTzYN7HtwFt u+rU6wJnprxQf/JvP7beffH5fBIwGIZqEutJUlCKSNoFjYbQiihOkFmih0FJgSUGIpGxstE6RwiLQmsyzcXZesO8N1773YOHKPfUv/uxP726ePjsVNVoT9WZjMq02kRpEKay9+UPXjQmAL1991UuDZ+fGQulSVQrpuqg4pWkkupSjVGshtGZJpzQ9DysfQqZIkgzR7 jAc+qAFrm2xTIRJJKnr0okTfCnQKLRlo9MUicGWL7dcnCnytoOTKTxpERpBv8moomm7AZFjEddb9EiHdhJhPJdYanQKUZrivmH7Pnlm+itFuVgdi7WkpSSJdFlqRwRugLAkQakXJQ06cAhcB0tnRI0mstOllKYEvk8qJJGj8IygID16hwZBGIzIsIXCRREq6DGSsu9RkBYBBldKbCFwbMnA2mH8wKIrbQrGY1WkKbQ6DFkWOQEicMks8JTEQRJI0LOLJbvxwosTMlMk0kYbjTCGci4gzrr0Sod0YQFHWiSuRTHMkbRaCCxMZlh2FLGQLEjBmHFIhUBrEI0OlgYnyNN0LFKliYxGeT69rouqtOjP5+lLEtxugosgOjNHj7ZRGmwjaDoGX9skKEQQIFptkAIjIWckCQIrE9ija8aOznk5wiwh9lw8aeMlMamUeEKis4wOFiaFRtpEYxBJSoQA4ZM4ksgSPG4E9Siibjt02xUaUQsnzFFfSZlPM4TRlPp7yQWCs/PzlMs53HrMRLGPt/f2UFYRbkOzbGm6JkPgYjAgbVo6I/Ntup0unuPgWAK0RaLVy//AfVe864lgcWkicz1yloNvoJMmpFLTsiCJNIFt0VERHdcnGyxPW5598BmlJo6tVPc9v1RB2CHdqMWOYpkLCwHnhyHVTHNcpTxUrVCp1rAtyYZ1w0i3SLFk89A3/g2UZH3O4ubL30RxsU5ldhkpDFJIbGFRE4rYSLQQRHGEJQQeFm7gYHaev98CuO6NF62q1hqTKktJlKarNW0JDZUgHA9dys/Y q4emnQ3Df3nxj7z7+t2f+pO/Ysv5U0dm525uKYty3wCetPjRdYNcjaaQabq1Oq1MkVOKkc1reGFhiWIuj7C6JGlKyZNsNor3n7eFStLlkcoKz61fvX/79u3T9cWliTBWvrQEHa0QQmIZgdIK27FQmaKVxIRbN+77z5/4sT/+1PjJEycmosWVmXJvP3YpZM3aNYyuWz dTuHLPf5lPrnr3VXtPnDp10HNDlIqROEwO9fG+VosXspQ7lyto3+fE8ln2rlpDfniQP332WRCCd75tB43jZ7jUDRlspTiugxAeR+I2960s0hBy3503fmT69FcfONian5uQliDIF+m2YyKlUUIRxRF968eOfuC+r+4851Hill//+PiRx79ztNrs0mm0KZaLZEnGWwsB725WOFRv8HAmSDodSo7D3oF+bMfirxbOYkKHQDhc5lusznxaaO6fO8O2fIE9vf1M0+Go0jM73nT55EcvGa8duedr+3S1si8v7VLnzDxRpkjCHGJ4aHr1utVT7/mzP6/b5wJ++v57izf9wi8dVNrHcT3yxQK27RJ3Y6zM0LI1b+0ZoFldIvFsxvsH6LMELQOpkST1GBVq3NIAvvC54ztPcTwRLOs2b+sf4u2RS5JFY1++5yt3XbXnvZPX3/n5W4FbH/nLA+ueuOeBG/zefG3ynW87+N3D3jkRuP3226fiVEwkOiV0bNIsJep28QOfqOAjl2DEElw1WCZKFGUtkK6h7fj4DpRKfURJjeGwSE/UJcJga4d6p0lHCoo64w1BkfsqtYnf/LVPHgSuAdh1476TwMsD3t9/9jUMc9pMSiGxJRgV0+22Wa7XqTfqHH7pON8u9/NE6BB5PnZPD42BkMe14IG4gVXIsVSvkijFU2fPIrOUraPrsD3Jlt4SnTQlsi2qtqLSarG0VJnaObHztu8HyTqX9vn6Aw/cMTw0TJpkeH6AhaIncCn3FkmFzWNzc3y7U+ObjTqPVJs8Vq1h1oScabdoV xWxyQg9l57BATZZDpuCgH5PMrVxM3G3g513WfNDW3liYRGsPN1ua2LHtq0zM6dOPfmqCDx15227/+ILd58EaNa717/00smp3bsvo7fcS3VpGTcAKV2q1QZJ3MVIC88JsFJN2c+xbrDM+aHPlqE+ji0vY7kWvaFhaaXJzs3nYaoNNq/tJ1/tsiwtnpEOtz/+HHNLMXG UkmYp7XarVKlWD53TQtO89+7iN//stoPWqdkpPx/Wur3F6WccZ+KFdnuskXNZaCVkiWJ++Qy+59EbuHi6y1t2XkL27Ak2CJssS6lHMYPCYDLDP/dJvj1fQ0qb+WoMqk3BzrFlYAidc5hZXAQnh9DQ6TbRQhF3U7Is4eZf+YWJj9308Se/5z7w3fH8s8fGnNOnp1ZJie52S+VOd2oIeJObo2Vs5i2JWZWn1e/TrjQZK/WSiyPCE2eImh1S12PJaEJtYbsCN81oL7eROPQVodVI6ZiA1MvxQhyhOxGWlcOkKUHg4aQOaaoQ0hDFXf7pi3dPAk+e00r56HuurubnzpZsY5NKiYMhwUagcY1CCINB0pACIQXLoaBHWdTbXbTwWHEhHwQE9SbVgRJ/Mz/Hi4sr7H3fOIuVJvc+OEsYFnG8AKETGs0WljBYtk2j3nkZmRDoqMPqdSNHHztyZOc5rZTpQHlfIh2MpdDSgAZbZ/hGgzRIaSEF9AiNLyWylRFbNh0bfKEZsCxkK2JxZJi/Pv0CJyornLd5DQ8++hxHv7NIEFg0W00ajRqNRh3XtciUot5okBlFZgzSssm04fjxExN/+kcHxs+JwOWHDh06u3bkQNV1a7ZSIDWehEQoUgEaQGtMlpHlLXp6XPLdjFyqwBMsAvfR5D4Z0fFKbNqwgWajgnQHWF6K8V0H35EIrQFodWKSzGAJQc63sS2JylKkZaO1ZnTNqplXpUo07727+NV/vPuAv3D2hrWpRtYaZJbEwmBlINf00144S35kgMZsxEpgc0zEfL3Spu 1LklihlU2u6NBtNZDaohXHIDKadYWRLsZkZFhgNCaLcB2XzECWalAZhR6v9vzx472v+BF/dxSu3FPf9cY3z0TNLgO+YFNfHzozJHFE4CvW1CPGBvtYabQ5YQuON+aI7YCqUTSX2hgTUeop025IstSiv1wiUQu4fkiz2SBTHaSQ9AQOaZqBk6MTdzFGYAnB0FAvWjD9 fVWJ7xUjI+XJ54/NMNeVLM3XMEZjWRYGzf2dWUp5kJZNmlmE+RDdaXHpznFOzc6xOL8AKIqlArVaTKdTQSvD4sIifb29KOOgshaOJal0UzSgjcQYyNKU4zMzXHTR+F2vSRdKOm3CnIvnO4QFn77ePL7vErVaqLhN4OUYcGHL+j7iVoeBoX5mT5+mtjzHeRtLDA2UWFqYx3c8Ot2MocE875y8iMCHLElIogytDVJKjFIYLUiiCKVihkeGD379Xx869JoICGHj2C4qU2ASFqsLNFptvMBj9ZoSlzgen7hiFz919QQDoWB+9gwqU4SFXk6eXGHN6kH6e21Wls7SX3Zot5t889HvUKlFL8ssJkOgAIXv2+gswqiYjRvHjv7qr+zb94qEre8Vnu/juRlKCTJlgQhBxdRaTVb1lNh7yRb41tOUR99G72Afza6h0e7gezZWOMzRY7NIZVHoyVOtxli2hSUEaarJlwLqOqOTaoTMYVmagXKOQnHk6O/+7u9MTl5xZf01D3NrR0dK7W58pe/naHS7SB1z7fg6fm58I2/OuRSencH2HIIffjNzLRhfv5ZGo85itU6aSRr1Jq6laEcJjcgwWA7YMOoS5B2WKx38oEAUJURRhko1nm9P/8EffvrK7wf+FbfQjT/zUwdzoTvTjVv4UlK0XHZs3UTZd1mbaqyiCwKc02d4v51ycW2Zy9Zvw+AQ5DxW9RcoFwRDZZ9VA2UAdu26iD3vupQLto5SrXSwpIPjKsbWr+aDH/zg/lcC/pzU6Y98eO/4iReem67WOyU/6KFdX2S kELLRU3y0d5Cg1aEZBqSxQJdtprXL5546guXm6QtCwmKOTrvC2NoSq8tw8fYSDx9t8tATVSqNOo16lzdech7Ndrz/a4e/9fqr05+57dCTW7edtz/fE2JIySyHlxqKr8+3OFXooykND8ocf1vwuD1WHO1G5AKPUi5EYVGpLeA4OcqhZtVASKtjkLZFpjM6nZjNG0dnN p63fepcwL8qf+BdV+x+YGmxNimRtNOUJI3Z1APX7NjBPxx5ntjLQRLTTBKGSz4jwz3UajWGhgap1uqcPFXh0ovX88zTz1Mo9tJNQdiF6d273zh1y29/un6ueM7ZH7hw24apfGDPJN02ri0phXlUaZi/e3qGSpziOgKjI8qhS73eQKuUIBAsLS3i+x5DQ0W6zRUyY1hpiNrAwND+PXve+6rAv2qH5rdv+dXxr933tbtWlqpj/cOjkAkWaosUHUW5UGBmYZF1AwM0WjUKvX2g25TLJZ56dh7Pztg5vmFm8vIL9udHLrtr6trrXxXw12wxTd9/b/ETt95y15lTC5Pbtu2gUVkgaTeItSJKDI4Fo6t66cZtbNuiUu8QlvpnVq0auuGzd3758P8Jl3L6/nuLf3Tg05OWEJOFfH4iiuLJOMlYXmnSrDURaIxJEFJzwYXb9x+640u38v8hPvazP717+5atZtvmrWbN6vVm9dBqc83VP7znf6OW/Xok+a2b941XG9HY7KmTE81me/Khww+P5XMFkszQiFIKPQEQTwF3/58zui+98IK9KA4W8gVOn10kF4Tk8z7SdWl2I6JWA0fE9A+VqdXq0x/+iQ/f8PM3/cbJ14vAa7JZr3rXFR+bn188aFk2veUCxXIPQeiDkdQbbXKuZP3qIju3rcVKm7z9su2TTxy+a+Yzn3z/La8XAevVXrzu2j3jBnlXrVonVSmtbpdms40AwlyeTGeEtk2r00HYLhdsXc/OrR4XbVaU/Mbkb930nqme0rrowUefffIHTuC6a/fsPfbM C3d0WolfKhTp6clRyhcg04xtGCHt1Dh/rExRamYWGyxXa7xn1yYuvkAwP7fClg0Zhx+qr/rM7d+Yesc73nHD5OW7Zh478tRzPxACH/iRa245duzkAdsJfMuy8aXm/FUFlpeWWOm2WZidI9WapaUlFIaTlQ4jfR6/vO9D2NE32LTeYnZOUmnA6PAohx9+qnTy1NnrP/ Cj15cu23XZI4/826Px/xqB37z547sPH374oOvnKTsOb+1zuCoImZARM8ZiLlKkXcWOcoFRJ+Do/CwFO4e2DEe+9Ti+ZXA8ny/cU+X4bMKRZxZIVEiqXI6/+NKuUzPHb7z40ovnX3zx+Ctuq38HyuqWG7Tu+A0AAAAASUVORK5CYII= X-Mailer: Evolution 3.2.3-0ubuntu6 Xref: news.gmane.org gmane.linux.lib.musl.general:3276 Archived-At: --=-10x4I/XvLb9qCzw1NUsO Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Am Mittwoch, den 01.05.2013, 22:47 -0400 schrieb Rich Felker: > In any case, I think all of these issues are good arguments that > nobodu should ever use clock_t or the clock() function... Hm, AFAIR clock() is the only available function in C alone (including C11) that gives access to something like the "processor time". C11 a bit more of time handling to have access to something like a real time clock, but for processor time clock() is the only one. (MS got that wrong, but this is their problem.) So I think it still makes sense to use it for "short" measures, not for the whole run of a program. The standard suggests, I think, that you'd take a point of measure before and after the interval that interests you. For such a strategy to work you'd either have to know that no overflow can reasonably occur (by having a wide type) or that it may do no harm (by using an unsigned type). I would prefer to have both worlds by using uint64_t (or directly the underlying base type) uniformly. There is no reason to have it signed: - this is "processor time" and not wallclock time, so it should be monotonic, and not be affected by setting the system time - an application should always subtract the first value of a measure from the second - an application should never expect to be able to measure intervals that are longer than a few hours, and it can deduce the maximum time it has for a measure with CLOCKS_PER_SEC Jens --=20 :: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/ :: :: AlGorille ::::::::::::::: office Nancy : +33 383593090 :: :: ICube :::::::::::::: office Strasbourg : +33 368854536 :: :: ::::::::::::::::::::::::::: gsm France : +33 651400183 :: :: :::::::::::::::::::: gsm international : +49 15737185122 :: --=-10x4I/XvLb9qCzw1NUsO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAlGCH/cACgkQD9PoadrVN+IckACePQP9hxwrJIsA+ghMXKCZnUc7 +uQAn0UDriVE+0ZME8naVRJZCOEqvFHn =vh22 -----END PGP SIGNATURE----- --=-10x4I/XvLb9qCzw1NUsO-- From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3277 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: sign (in)consistency between architectures Date: Thu, 2 May 2013 12:13:51 +0200 Message-ID: <20130502101351.GO12689@port70.net> References: <51814B3F.4040005@eservices.virginia.edu> <20130501180015.GN12689@port70.net> <20130501200007.GM20323@brightrain.aerifal.cx> <20130501224132.GN20323@brightrain.aerifal.cx> <5181C3B4.4040801@eservices.virginia.edu> <20130502024753.GO20323@brightrain.aerifal.cx> <1367482359.28119.118.camel@eris.loria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1367489650 19208 80.91.229.3 (2 May 2013 10:14:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 May 2013 10:14:10 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3281-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 02 12:14:10 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UXqWb-0002hl-60 for gllmg-musl@plane.gmane.org; Thu, 02 May 2013 12:14:05 +0200 Original-Received: (qmail 7305 invoked by uid 550); 2 May 2013 10:14:03 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 7296 invoked from network); 2 May 2013 10:14:03 -0000 Content-Disposition: inline In-Reply-To: <1367482359.28119.118.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3277 Archived-At: * Jens Gustedt [2013-05-02 10:12:39 +0200]: > I would prefer to have both worlds by using uint64_t (or directly the > underlying base type) uniformly. There is no reason to have it signed: > yes probably that's the best solution but note that even that can hurt: i've seen code like t = (double)clock(); (eg the time module in python does this) where interesting low bits may get lost if clock_t is uint64_t this might be common because clock_t is permitted to be a floating-point type of course this should not be a problem if the cast is applied to the difference only (other than uint64->double conversion is usually much slower than int32->double conversion) ..but this issue is present on 64bit platforms anyway siginfo is affected as well: clock_t is used in the union in it which i think is aligned with glibc now but i'm not against the uint64_t solution if we decide breaking glibc abi here is ok From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3278 Path: news.gmane.org!not-for-mail From: Jens Gustedt Newsgroups: gmane.linux.lib.musl.general Subject: Re: sign (in)consistency between architectures Date: Thu, 02 May 2013 14:12:37 +0200 Message-ID: <1367496757.28119.196.camel@eris.loria.fr> References: <51814B3F.4040005@eservices.virginia.edu> <20130501180015.GN12689@port70.net> <20130501200007.GM20323@brightrain.aerifal.cx> <20130501224132.GN20323@brightrain.aerifal.cx> <5181C3B4.4040801@eservices.virginia.edu> <20130502024753.GO20323@brightrain.aerifal.cx> <1367482359.28119.118.camel@eris.loria.fr> <20130502101351.GO12689@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-YewQkPh3Cpt54+LP6YlD" X-Trace: ger.gmane.org 1367496779 30450 80.91.229.3 (2 May 2013 12:12:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 May 2013 12:12:59 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3282-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 02 14:12:57 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UXsNW-0003a0-Lh for gllmg-musl@plane.gmane.org; Thu, 02 May 2013 14:12:50 +0200 Original-Received: (qmail 23893 invoked by uid 550); 2 May 2013 12:12:49 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 23885 invoked from network); 2 May 2013 12:12:49 -0000 X-IronPort-AV: E=Sophos;i="4.87,595,1363129200"; d="scan'";a="15792259" In-Reply-To: <20130502101351.GO12689@port70.net> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAABHNCSVQICAgIfAhkiAAAEb9JREFUaN7VmXuQ3lV5xz/n/O7v7333fffdW3azSTY3Qi6wGy4aEc0qWlGhWcAq7WiDrWNpO61paS29EpzWaevYpvfL2JK0VRBbBxQtg0U2BRGKhIAI4ZKwSTbZ+3u//G7nnP7BtGM7UyVAnfb56/xznuf7nXnOnOf5fuH/eYjXI8mDn/5k8ch90xNj+eKka8xkI1MTGmY6Rk/XpD5w091fPvnf7xz8sQ/sLTQ6k54SY2mW1mQY3DVX8Kdv/PvPnfyBE7hn797bxBPP3NBv28RAqgyzJqNgJIs5q7bhHW+94Yd+5/fuBrjj5l/cs/LUs/vNiVMTo5aNJQX9lks3iaivHqlt/9D7xs778Y/Uf6AE/uWa6x7wT52ZTDyLKEkoOHmW4oSaSDFxQmq7tHPuDJ5TUkv10iAGgSLvediZotf16HS6KG1RuXDT/g99/vO3vtLa8vUgELuCVAja0mVJKRaylGbgYnwP27bImYRcozkmKrWS53vYjosfhNSUIjXQUoq2K0ksRdZqTZ5Lbfs/Dl/66E/uSebmb8hF8URab48JS+IPDVJtto9uuHj8wKW//6lD/1OSznxtLEPRv2kdPH2MSBpkqlDGkLoOIgGkIWcEiTYsk1JSDpGUFAAcBzfRCKXxV+ql7/XWnn7uxcm3vOGS2rrR1UcLV+6pC4B//tjPjGdHjhwttFOEcMmMAgFeLkezWsOTkmigfyYZGTzYN7HtwFt u+rU6wJnprxQf/JvP7beffH5fBIwGIZqEutJUlCKSNoFjYbQiihOkFmih0FJgSUGIpGxstE6RwiLQmsyzcXZesO8N1773YOHKPfUv/uxP726ePjsVNVoT9WZjMq02kRpEKay9+UPXjQmAL1991UuDZ+fGQulSVQrpuqg4pWkkupSjVGshtGZJpzQ9DysfQqZIkgzR7 jAc+qAFrm2xTIRJJKnr0okTfCnQKLRlo9MUicGWL7dcnCnytoOTKTxpERpBv8moomm7AZFjEddb9EiHdhJhPJdYanQKUZrivmH7Pnlm+itFuVgdi7WkpSSJdFlqRwRugLAkQakXJQ06cAhcB0tnRI0mstOllKYEvk8qJJGj8IygID16hwZBGIzIsIXCRREq6DGSsu9RkBYBBldKbCFwbMnA2mH8wKIrbQrGY1WkKbQ6DFkWOQEicMks8JTEQRJI0LOLJbvxwosTMlMk0kYbjTCGci4gzrr0Sod0YQFHWiSuRTHMkbRaCCxMZlh2FLGQLEjBmHFIhUBrEI0OlgYnyNN0LFKliYxGeT69rouqtOjP5+lLEtxugosgOjNHj7ZRGmwjaDoGX9skKEQQIFptkAIjIWckCQIrE9ija8aOznk5wiwh9lw8aeMlMamUeEKis4wOFiaFRtpEYxBJSoQA4ZM4ksgSPG4E9Siibjt02xUaUQsnzFFfSZlPM4TRlPp7yQWCs/PzlMs53HrMRLGPt/f2UFYRbkOzbGm6JkPgYjAgbVo6I/Ntup0unuPgWAK0RaLVy//AfVe864lgcWkicz1yloNvoJMmpFLTsiCJNIFt0VERHdcnGyxPW5598BmlJo6tVPc9v1RB2CHdqMWOYpkLCwHnhyHVTHNcpTxUrVCp1rAtyYZ1w0i3SLFk89A3/g2UZH3O4ubL30RxsU5ldhkpDFJIbGFRE4rYSLQQRHGEJQQeFm7gYHaev98CuO6NF62q1hqTKktJlKarNW0JDZUgHA9dys/Y q4emnQ3Df3nxj7z7+t2f+pO/Ysv5U0dm525uKYty3wCetPjRdYNcjaaQabq1Oq1MkVOKkc1reGFhiWIuj7C6JGlKyZNsNor3n7eFStLlkcoKz61fvX/79u3T9cWliTBWvrQEHa0QQmIZgdIK27FQmaKVxIRbN+77z5/4sT/+1PjJEycmosWVmXJvP3YpZM3aNYyuWz dTuHLPf5lPrnr3VXtPnDp10HNDlIqROEwO9fG+VosXspQ7lyto3+fE8ln2rlpDfniQP332WRCCd75tB43jZ7jUDRlspTiugxAeR+I2960s0hBy3503fmT69FcfONian5uQliDIF+m2YyKlUUIRxRF968eOfuC+r+4851Hill//+PiRx79ztNrs0mm0KZaLZEnGWwsB725WOFRv8HAmSDodSo7D3oF+bMfirxbOYkKHQDhc5lusznxaaO6fO8O2fIE9vf1M0+Go0jM73nT55EcvGa8duedr+3S1si8v7VLnzDxRpkjCHGJ4aHr1utVT7/mzP6/b5wJ++v57izf9wi8dVNrHcT3yxQK27RJ3Y6zM0LI1b+0ZoFldIvFsxvsH6LMELQOpkST1GBVq3NIAvvC54ztPcTwRLOs2b+sf4u2RS5JFY1++5yt3XbXnvZPX3/n5W4FbH/nLA+ueuOeBG/zefG3ynW87+N3D3jkRuP3226fiVEwkOiV0bNIsJep28QOfqOAjl2DEElw1WCZKFGUtkK6h7fj4DpRKfURJjeGwSE/UJcJga4d6p0lHCoo64w1BkfsqtYnf/LVPHgSuAdh1476TwMsD3t9/9jUMc9pMSiGxJRgV0+22Wa7XqTfqHH7pON8u9/NE6BB5PnZPD42BkMe14IG4gVXIsVSvkijFU2fPIrOUraPrsD3Jlt4SnTQlsi2qtqLSarG0VJnaObHztu8HyTqX9vn6Aw/cMTw0TJpkeH6AhaIncCn3FkmFzWNzc3y7U+ObjTqPVJs8Vq1h1oScabdoV xWxyQg9l57BATZZDpuCgH5PMrVxM3G3g513WfNDW3liYRGsPN1ua2LHtq0zM6dOPfmqCDx15227/+ILd58EaNa717/00smp3bsvo7fcS3VpGTcAKV2q1QZJ3MVIC88JsFJN2c+xbrDM+aHPlqE+ji0vY7kWvaFhaaXJzs3nYaoNNq/tJ1/tsiwtnpEOtz/+HHNLMXG UkmYp7XarVKlWD53TQtO89+7iN//stoPWqdkpPx/Wur3F6WccZ+KFdnuskXNZaCVkiWJ++Qy+59EbuHi6y1t2XkL27Ak2CJssS6lHMYPCYDLDP/dJvj1fQ0qb+WoMqk3BzrFlYAidc5hZXAQnh9DQ6TbRQhF3U7Is4eZf+YWJj9308Se/5z7w3fH8s8fGnNOnp1ZJie52S+VOd2oIeJObo2Vs5i2JWZWn1e/TrjQZK/WSiyPCE2eImh1S12PJaEJtYbsCN81oL7eROPQVodVI6ZiA1MvxQhyhOxGWlcOkKUHg4aQOaaoQ0hDFXf7pi3dPAk+e00r56HuurubnzpZsY5NKiYMhwUagcY1CCINB0pACIQXLoaBHWdTbXbTwWHEhHwQE9SbVgRJ/Mz/Hi4sr7H3fOIuVJvc+OEsYFnG8AKETGs0WljBYtk2j3nkZmRDoqMPqdSNHHztyZOc5rZTpQHlfIh2MpdDSgAZbZ/hGgzRIaSEF9AiNLyWylRFbNh0bfKEZsCxkK2JxZJi/Pv0CJyornLd5DQ8++hxHv7NIEFg0W00ajRqNRh3XtciUot5okBlFZgzSssm04fjxExN/+kcHxs+JwOWHDh06u3bkQNV1a7ZSIDWehEQoUgEaQGtMlpHlLXp6XPLdjFyqwBMsAvfR5D4Z0fFKbNqwgWajgnQHWF6K8V0H35EIrQFodWKSzGAJQc63sS2JylKkZaO1ZnTNqplXpUo07727+NV/vPuAv3D2hrWpRtYaZJbEwmBlINf00144S35kgMZsxEpgc0zEfL3Spu 1LklihlU2u6NBtNZDaohXHIDKadYWRLsZkZFhgNCaLcB2XzECWalAZhR6v9vzx472v+BF/dxSu3FPf9cY3z0TNLgO+YFNfHzozJHFE4CvW1CPGBvtYabQ5YQuON+aI7YCqUTSX2hgTUeop025IstSiv1wiUQu4fkiz2SBTHaSQ9AQOaZqBk6MTdzFGYAnB0FAvWjD9 fVWJ7xUjI+XJ54/NMNeVLM3XMEZjWRYGzf2dWUp5kJZNmlmE+RDdaXHpznFOzc6xOL8AKIqlArVaTKdTQSvD4sIifb29KOOgshaOJal0UzSgjcQYyNKU4zMzXHTR+F2vSRdKOm3CnIvnO4QFn77ePL7vErVaqLhN4OUYcGHL+j7iVoeBoX5mT5+mtjzHeRtLDA2UWFqYx3c8Ot2MocE875y8iMCHLElIogytDVJKjFIYLUiiCKVihkeGD379Xx869JoICGHj2C4qU2ASFqsLNFptvMBj9ZoSlzgen7hiFz919QQDoWB+9gwqU4SFXk6eXGHN6kH6e21Wls7SX3Zot5t889HvUKlFL8ssJkOgAIXv2+gswqiYjRvHjv7qr+zb94qEre8Vnu/juRlKCTJlgQhBxdRaTVb1lNh7yRb41tOUR99G72Afza6h0e7gezZWOMzRY7NIZVHoyVOtxli2hSUEaarJlwLqOqOTaoTMYVmagXKOQnHk6O/+7u9MTl5xZf01D3NrR0dK7W58pe/naHS7SB1z7fg6fm58I2/OuRSencH2HIIffjNzLRhfv5ZGo85itU6aSRr1Jq6laEcJjcgwWA7YMOoS5B2WKx38oEAUJURRhko1nm9P/8EffvrK7wf+FbfQjT/zUwdzoTvTjVv4UlK0XHZs3UTZd1mbaqyiCwKc02d4v51ycW2Zy9Zvw+AQ5DxW9RcoFwRDZZ9VA2UAdu26iD3vupQLto5SrXSwpIPjKsbWr+aDH/zg/lcC/pzU6Y98eO/4iReem67WOyU/6KFdX2S kELLRU3y0d5Cg1aEZBqSxQJdtprXL5546guXm6QtCwmKOTrvC2NoSq8tw8fYSDx9t8tATVSqNOo16lzdech7Ndrz/a4e/9fqr05+57dCTW7edtz/fE2JIySyHlxqKr8+3OFXooykND8ocf1vwuD1WHO1G5AKPUi5EYVGpLeA4OcqhZtVASKtjkLZFpjM6nZjNG0dnN p63fepcwL8qf+BdV+x+YGmxNimRtNOUJI3Z1APX7NjBPxx5ntjLQRLTTBKGSz4jwz3UajWGhgap1uqcPFXh0ovX88zTz1Mo9tJNQdiF6d273zh1y29/un6ueM7ZH7hw24apfGDPJN02ri0phXlUaZi/e3qGSpziOgKjI8qhS73eQKuUIBAsLS3i+x5DQ0W6zRUyY1hpiNrAwND+PXve+6rAv2qH5rdv+dXxr933tbtWlqpj/cOjkAkWaosUHUW5UGBmYZF1AwM0WjUKvX2g25TLJZ56dh7Pztg5vmFm8vIL9udHLrtr6trrXxXw12wxTd9/b/ETt95y15lTC5Pbtu2gUVkgaTeItSJKDI4Fo6t66cZtbNuiUu8QlvpnVq0auuGzd3758P8Jl3L6/nuLf3Tg05OWEJOFfH4iiuLJOMlYXmnSrDURaIxJEFJzwYXb9x+640u38v8hPvazP717+5atZtvmrWbN6vVm9dBqc83VP7znf6OW/Xok+a2b941XG9HY7KmTE81me/Khww+P5XMFkszQiFIKPQEQTwF3/58zui+98IK9KA4W8gVOn10kF4Tk8z7SdWl2I6JWA0fE9A+VqdXq0x/+iQ/f8PM3/cbJ14vAa7JZr3rXFR+bn188aFk2veUCxXIPQeiDkdQbbXKuZP3qIju3rcVKm7z9su2TTxy+a+Yzn3z/La8XAevVXrzu2j3jBnlXrVonVSmtbpdms40AwlyeTGeEtk2r00HYLhdsXc/OrR4XbVaU/Mbkb930nqme0rrowUefffIHTuC6a/fsPfbM C3d0WolfKhTp6clRyhcg04xtGCHt1Dh/rExRamYWGyxXa7xn1yYuvkAwP7fClg0Zhx+qr/rM7d+Yesc73nHD5OW7Zh478tRzPxACH/iRa245duzkAdsJfMuy8aXm/FUFlpeWWOm2WZidI9WapaUlFIaTlQ4jfR6/vO9D2NE32LTeYnZOUmnA6PAohx9+qnTy1NnrP/ Cj15cu23XZI4/826Px/xqB37z547sPH374oOvnKTsOb+1zuCoImZARM8ZiLlKkXcWOcoFRJ+Do/CwFO4e2DEe+9Ti+ZXA8ny/cU+X4bMKRZxZIVEiqXI6/+NKuUzPHb7z40ovnX3zx+Ctuq38HyuqWG7Tu+A0AAAAASUVORK5CYII= X-Mailer: Evolution 3.2.3-0ubuntu6 Xref: news.gmane.org gmane.linux.lib.musl.general:3278 Archived-At: --=-YewQkPh3Cpt54+LP6YlD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Am Donnerstag, den 02.05.2013, 12:13 +0200 schrieb Szabolcs Nagy: > * Jens Gustedt [2013-05-02 10:12:39 +0200]: > > I would prefer to have both worlds by using uint64_t (or directly the > > underlying base type) uniformly. There is no reason to have it signed: > >=20 >=20 > yes probably that's the best solution >=20 > but note that even that can hurt: i've seen code like >=20 > t =3D (double)clock(); >=20 > (eg the time module in python does this) where interesting > low bits may get lost if clock_t is uint64_t *and* if the actual value is larger than (1ull << 50) or something like that. An application that is interested in the low bits (probably most of them are) should probably compute the integer and fractional parts of the time in seconds by using CLOCKS_PER_SECOND, anyhow. > this might be common because clock_t is permitted to be > a floating-point type yes, any real type is permitted in C, I think. Jens --=20 :: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/ :: :: AlGorille ::::::::::::::: office Nancy : +33 383593090 :: :: ICube :::::::::::::: office Strasbourg : +33 368854536 :: :: ::::::::::::::::::::::::::: gsm France : +33 651400183 :: :: :::::::::::::::::::: gsm international : +49 15737185122 :: --=-YewQkPh3Cpt54+LP6YlD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAlGCWDUACgkQD9PoadrVN+JCcACeKg5iEZ+E0otAZhSVmy19cpZl JnoAni0oqoRY46AYp5nZYh9k+WQXyhU2 =GAWL -----END PGP SIGNATURE----- --=-YewQkPh3Cpt54+LP6YlD-- From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3279 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: sign (in)consistency between architectures Date: Thu, 2 May 2013 15:08:03 +0200 Message-ID: <20130502130802.GP12689@port70.net> References: <51814B3F.4040005@eservices.virginia.edu> <20130501180015.GN12689@port70.net> <20130501200007.GM20323@brightrain.aerifal.cx> <20130501224132.GN20323@brightrain.aerifal.cx> <5181C3B4.4040801@eservices.virginia.edu> <20130502024753.GO20323@brightrain.aerifal.cx> <1367482359.28119.118.camel@eris.loria.fr> <20130502101351.GO12689@port70.net> <1367496757.28119.196.camel@eris.loria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1367500096 1848 80.91.229.3 (2 May 2013 13:08:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 May 2013 13:08:16 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3283-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 02 15:08:16 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UXtFA-0001AD-0e for gllmg-musl@plane.gmane.org; Thu, 02 May 2013 15:08:16 +0200 Original-Received: (qmail 21566 invoked by uid 550); 2 May 2013 13:08:14 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 21558 invoked from network); 2 May 2013 13:08:14 -0000 Content-Disposition: inline In-Reply-To: <1367496757.28119.196.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3279 Archived-At: * Jens Gustedt [2013-05-02 14:12:37 +0200]: > Am Donnerstag, den 02.05.2013, 12:13 +0200 schrieb Szabolcs Nagy: > > > > t = (double)clock(); > > > > (eg the time module in python does this) where interesting > > low bits may get lost if clock_t is uint64_t > > > *and* if the actual value is larger than (1ull << 50) or something > like that. larger than (1ull << 53) so it does not matter if the counter always start from 0 at process startup btw the times() fallback in the current clock code seems to be wrong: it multiplies the result by 100 which would mean 10000 Hz kernel clock tick