Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #86894 > unrolled thread
| Started by | Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> |
|---|---|
| First post | 2022-10-12 15:57 -0700 |
| Last post | 2022-10-15 11:34 +0200 |
| Articles | 20 on this page of 106 — 22 participants |
Back to article view | Back to comp.lang.c++
CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-12 15:57 -0700
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-12 16:01 -0700
Re: CHAR_BIT is not eight Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-10-12 17:16 -0700
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-13 11:38 +0200
Re: CHAR_BIT is not eight Michael S <already5chosen@yahoo.com> - 2022-11-16 06:24 -0800
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-11-17 11:04 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-11-17 16:40 +0000
Re: CHAR_BIT is not eight Richard Damon <Richard@Damon-Family.org> - 2022-11-17 23:23 -0500
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-11-18 08:16 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-11-18 16:33 +0000
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-11-18 18:54 +0100
Re: CHAR_BIT is not eight Michael S <already5chosen@yahoo.com> - 2022-11-18 03:47 -0800
Re: CHAR_BIT is not eight scott@slp53.sl.home (Scott Lurndal) - 2022-11-18 14:52 +0000
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-11-18 16:32 +0000
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-11-18 19:05 +0100
Re: CHAR_BIT is not eight scott@slp53.sl.home (Scott Lurndal) - 2022-11-18 18:16 +0000
Re: CHAR_BIT is not eight Juha Nieminen <nospam@thanks.invalid> - 2022-10-13 08:02 +0000
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-13 08:08 +0000
Re: CHAR_BIT is not eight Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-15 11:35 +0200
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-15 02:53 -0700
Re: CHAR_BIT is not eight Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-15 11:57 +0200
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-15 03:05 -0700
Re: CHAR_BIT is not eight Juha Nieminen <nospam@thanks.invalid> - 2022-10-17 06:18 +0000
Re: CHAR_BIT is not eight Lynn McGuire <lynnmcguire5@gmail.com> - 2022-10-17 15:29 -0500
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-13 02:06 -0700
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-13 11:42 +0200
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-13 15:36 +0000
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-13 23:06 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-13 22:30 +0100
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-14 15:27 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-14 14:47 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-14 14:58 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-14 21:01 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-15 10:28 +0000
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-15 13:39 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 12:45 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-15 15:18 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 16:24 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-15 15:34 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 16:39 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-15 15:53 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 16:55 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-15 15:57 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 16:59 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-17 15:27 +0000
Re: CHAR_BIT is not eight "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-10-17 09:04 -0700
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-17 16:13 +0000
Re: CHAR_BIT is not eight red floyd <no.spam.here@its.invalid> - 2022-10-17 09:44 -0700
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-17 17:47 +0100
Re: CHAR_BIT is not eight Manfred <noname@add.invalid> - 2022-10-18 01:10 +0200
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-17 16:22 -0700
Re: CHAR_BIT is not eight Paul N <gw7rib@aol.com> - 2022-10-18 05:13 -0700
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-18 15:04 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-18 17:40 +0100
Re: CHAR_BIT is not eight "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-10-18 12:14 -0700
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-19 15:12 +0000
Re: CHAR_BIT is not eight scott@slp53.sl.home (Scott Lurndal) - 2022-10-19 15:35 +0000
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-20 16:16 +0000
Re: CHAR_BIT is not eight Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-15 20:13 +0200
Re: CHAR_BIT is not eight Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-15 20:11 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 20:03 +0100
Re: CHAR_BIT is not eight Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-16 07:51 +0200
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-16 17:03 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-16 16:34 +0100
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-16 18:51 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-16 18:11 +0100
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-16 19:18 +0100
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-16 22:02 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-16 21:19 +0100
Re: CHAR_BIT is not eight scott@slp53.sl.home (Scott Lurndal) - 2022-10-16 21:24 +0000
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-16 14:38 -0700
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-16 14:48 -0700
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-16 22:39 +0100
Re: CHAR_BIT is not eight scott@slp53.sl.home (Scott Lurndal) - 2022-10-16 23:49 +0000
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-17 09:54 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-17 17:31 +0100
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-17 19:56 +0200
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-17 15:29 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-17 17:33 +0100
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-15 11:55 -0700
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-15 13:06 -0700
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-15 15:42 -0700
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-16 19:10 +0200
Re: CHAR_BIT is not eight Vir Campestris <vir.campestris@invalid.invalid> - 2022-10-16 21:28 +0100
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-17 10:09 +0200
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-16 13:35 -0700
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-16 13:36 -0700
Re: CHAR_BIT is not eight Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-02 17:46 -0700
Re: CHAR_BIT is not eight Bo Persson <bo@bo-persson.se> - 2022-10-13 11:10 +0200
Re: CHAR_BIT is not eight Juha Nieminen <nospam@thanks.invalid> - 2022-10-13 10:49 +0000
Re: CHAR_BIT is not eight Juha Nieminen <nospam@thanks.invalid> - 2022-10-13 12:05 +0000
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-13 06:34 -0700
Re: CHAR_BIT is not eight Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-13 15:24 +0100
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-13 15:59 +0200
Re: CHAR_BIT is not eight Juha Nieminen <nospam@thanks.invalid> - 2022-10-14 05:54 +0000
Re: CHAR_BIT is not eight Paavo Helde <eesnimi@osa.pri.ee> - 2022-10-14 09:16 +0300
Re: CHAR_BIT is not eight Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-16 05:41 -0800
Re: CHAR_BIT is not eight Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-16 10:38 -0800
Re: CHAR_BIT is not eight Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-05 11:42 -0800
Re: CHAR_BIT is not eight Öö Tiib <ootiib@hot.ee> - 2022-12-06 01:03 -0800
Re: CHAR_BIT is not eight Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-28 20:49 -0800
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-14 00:17 -0700
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-14 15:33 +0200
Re: CHAR_BIT is not eight Vir Campestris <vir.campestris@invalid.invalid> - 2022-10-16 21:37 +0100
Re: CHAR_BIT is not eight Lynn McGuire <lynnmcguire5@gmail.com> - 2022-10-17 15:24 -0500
Re: CHAR_BIT is not eight Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-15 11:34 +0200
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-10-15 13:06 -0700 |
| Message-ID | <tif3rh$2t8mc$2@dont-email.me> |
| In reply to | #86993 |
On 10/15/2022 11:55 AM, Frederick Virchanza Gotham wrote: > On Saturday, October 15, 2022 at 12:39:42 PM UTC+1, David Brown wrote: > >> (It is relatively rare that you have to worry about /every/ byte of code >> or data space, however - though it does happen.) > > > My cryptography code is just slightly too big for the microcontroller. So I will be pinching bytes here and there. Did you actually write the cipher? Or did you get the code from GitHub?
[toc] | [prev] | [next] | [standalone]
| From | Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> |
|---|---|
| Date | 2022-10-15 15:42 -0700 |
| Message-ID | <80d4f942-0740-455e-96e7-c21fd561291fn@googlegroups.com> |
| In reply to | #86996 |
On Saturday, October 15, 2022 at 9:06:25 PM UTC+1, Chris M. Thomasson wrote: > Did you actually write the cipher? Or did you get the code from GitHub? I can't find an algorithm that will fit on the microcontroller so I'm writing my own. 99% of the program memory is already taken up.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-10-16 19:10 +0200 |
| Message-ID | <tihdun$3683u$4@dont-email.me> |
| In reply to | #86998 |
On 16/10/2022 00:42, Frederick Virchanza Gotham wrote: > On Saturday, October 15, 2022 at 9:06:25 PM UTC+1, Chris M. Thomasson wrote: > >> Did you actually write the cipher? Or did you get the code from GitHub? > > > I can't find an algorithm that will fit on the microcontroller so I'm writing my own. > 99% of the program memory is already taken up. This was for an Arduino, using an 8-bit AVR ? Have you much experience with the device? And are you using the Arduino toolchain and IDE, or a plain avr-gcc build? The Arduino toolchain can make it difficult to optimise well - you have limited control of the build flags. And the Ardunio libraries are designed for ease of use for beginners, not efficiency. (At least, this was all the case last time I tried it.) In general for the AVR, make sure you use uint8_t types whenever possible, as they are much more efficient than "int". Avoid pointers, and use statically allocated data as much as you can. Make sure you have "-fno-rtti -fno-exceptions". Check the generated assembly code - the AVR backend is underfunded and understaffed, so though the people who have worked on it have done a fantastic job, there are many "missed optimisation opportunity" issues and missing peephole optimisations. That means that sometimes small changes to the source code with no real semantic differences can sometimes lead to significant object code changes. Fancy branchless expressions or heavy use of tertiary operators that give efficient results on an x86 could end up much worse results than simple branched code. Avoid divisions, and avoid any floating point. Remember that on this kind of device, even shift operators are slow (especially for anything bigger than 8-bit). Much the same applies to the TMS320 (except you want uint16_t, not uint8_t !). But be wary of trying to read the generated TMS320 assembly code. AVR assembly is easy to understand - TMS320 assembly will drive you insane.
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2022-10-16 21:28 +0100 |
| Message-ID | <tihphj$37j3o$2@dont-email.me> |
| In reply to | #86998 |
On 15/10/2022 23:42, Frederick Virchanza Gotham wrote: > On Saturday, October 15, 2022 at 9:06:25 PM UTC+1, Chris M. Thomasson wrote: > >> Did you actually write the cipher? Or did you get the code from GitHub? > > > I can't find an algorithm that will fit on the microcontroller so I'm writing my own. > 99% of the program memory is already taken up. I too have been in the position where every byte counts. Abbreviating error messages was usually the easiest fix. But... I've also done a reasonable amount of cryptography. A home rolled algorithm will usually have a hole in it somewhere. You'll get away with it if the stuff you are protecting is obscure enough, and not worth a lot, but I wouldn't trust my life or any serious amounts of money to it. Good luck Andy
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-10-17 10:09 +0200 |
| Message-ID | <tij2k2$3daer$1@dont-email.me> |
| In reply to | #87027 |
On 16/10/2022 22:28, Vir Campestris wrote: > On 15/10/2022 23:42, Frederick Virchanza Gotham wrote: >> On Saturday, October 15, 2022 at 9:06:25 PM UTC+1, Chris M. Thomasson >> wrote: >> >>> Did you actually write the cipher? Or did you get the code from GitHub? >> >> >> I can't find an algorithm that will fit on the microcontroller so I'm >> writing my own. >> 99% of the program memory is already taken up. > > I too have been in the position where every byte counts. Abbreviating > error messages was usually the easiest fix. > > But... > > I've also done a reasonable amount of cryptography. A home rolled > algorithm will usually have a hole in it somewhere. You'll get away with > it if the stuff you are protecting is obscure enough, and not worth a > lot, but I wouldn't trust my life or any serious amounts of money to it. > From his description, it sounds like the encryption does not have to cover more than a small code key. That reduces the risk somewhat - many attacks on encryption systems rely on sending specially crafted packets, or examining long encrypted streams where you can guess some of the original content (like html tags). For a short enough message, sent rarely, it's probably enough to xor the message bytes with the results of a pseudorandom generator. You don't need to re-implement OpenSSL for a 16 byte message. Still, it's a very good point you make - good encryption implementations are not always easy even if you have all the details of the algorithm. If the hardware is still in flux, an option is an external encryption chip. You can get small and cheap devices that are easy to integrate with such microcontrollers - Microchip (the manufacturers of the AVR in the Arduino) have them.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-10-16 13:35 -0700 |
| Message-ID | <tihpuo$37mcf$1@dont-email.me> |
| In reply to | #86998 |
On 10/15/2022 3:42 PM, Frederick Virchanza Gotham wrote: > On Saturday, October 15, 2022 at 9:06:25 PM UTC+1, Chris M. Thomasson wrote: > >> Did you actually write the cipher? Or did you get the code from GitHub? > > > I can't find an algorithm that will fit on the microcontroller so I'm writing my own. > 99% of the program memory is already taken up. http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=aa345a911d9845b1d0ef8b893fe7f534dde00fe26aadf14037a54ed0c2e61445f564779ed727521c95a887d7c0e3ec1cf02a015c44d237582358880ffc96ac5ed9ba29351832b9b2842942a22445b68ba863bb6ae6e0070ee7977c4f2c0e75e93a2e2438bfef3116d5722ef23a8796b4e2ad1eb7ac1580ef0db168211f008cc325aa4c4fcc30f55422bed0326a9f3c5345e122cdf81d7895f730538d13d9214fef34e681ee8eda0c95034e5ed0d347d8dc33049cfbf068461794f4691d6e505ca754c335bd8cf0f657bb2a5ddca959ca9afb492667b5d063b54c648b77dd93d4b2098141154bd57aaac8367b2b606d23c04558b12a08689acf7f9a05b836f16c
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-10-16 13:36 -0700 |
| Message-ID | <tihq0b$37mcf$2@dont-email.me> |
| In reply to | #87028 |
On 10/16/2022 1:35 PM, Chris M. Thomasson wrote: > On 10/15/2022 3:42 PM, Frederick Virchanza Gotham wrote: >> On Saturday, October 15, 2022 at 9:06:25 PM UTC+1, Chris M. Thomasson >> wrote: >> >>> Did you actually write the cipher? Or did you get the code from GitHub? >> >> >> I can't find an algorithm that will fit on the microcontroller so I'm >> writing my own. >> 99% of the program memory is already taken up. > > http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=aa345a911d9845b1d0ef8b893fe7f534dde00fe26aadf14037a54ed0c2e61445f564779ed727521c95a887d7c0e3ec1cf02a015c44d237582358880ffc96ac5ed9ba29351832b9b2842942a22445b68ba863bb6ae6e0070ee7977c4f2c0e75e93a2e2438bfef3116d5722ef23a8796b4e2ad1eb7ac1580ef0db168211f008cc325aa4c4fcc30f55422bed0326a9f3c5345e122cdf81d7895f730538d13d9214fef34e681ee8eda0c95034e5ed0d347d8dc33049cfbf068461794f4691d6e505ca754c335bd8cf0f657bb2a5ddca959ca9afb492667b5d063b54c648b77dd93d4b2098141154bd57aaac8367b2b606d23c04558b12a08689acf7f9a05b836f16c Do you have any SHA2 hashes up and running on the limited space system?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-11-02 17:46 -0700 |
| Message-ID | <865yfwhnkd.fsf@linuxsc.com> |
| In reply to | #86915 |
Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> writes: > On Thursday, October 13, 2022, Juha Nieminen wrote: > >> The vast, *vast* majority of C and C++ programmers assume that 'char' >> is always 8-bit, and sometimes write code making that assumption. >> It's *extremely* rare to see any code out there that uses CHAR_BIT at >> all, but it's quite common to see code that assumes that it's 8. >> Most C and C++ programmers just assume that it's a de-facto universal >> standard, and that the actual C and C++ standards are just antiquated >> in this regard, by keeping "backwards compatibility" with some more >> exotic CPUs from the 1970's that have been completely obsolete for >> decades. >> >> I suppose there's a good reason why the language standards don't >> assume that 'char' is 8 bits, after all. > > I totally agree. I've been using C++ compilers for about 20 years > now, and yesterday was the first time I encountered CHAR_BIT != 8. > Lots of my code uses "char unsigned" and "uint8_t" interchangeably. > > > On Thursday, October 13, 2022, Mut...@... wrote: > >> A number of current Texas Instruments DSPs have 16 bit chars. >> >> Personally I always use int8_t or uint8_t if I'm writing portable >> code just to be 100% sure. > > I'm writing a 'universal header file' today that will be used in a > program on: > 1) x86_64 desktop PC > 2) microcontroller Texas Instruments F2809 (with 16-Bit bytes) > 3) microcontroller Arduino sam3x8e > > If I include "cstdint", then it doesn't have "uint8_t" on the Texas > Instruments compiler. So I'm using "uint_least8_t" in the code. Easier just to use unsigned char.
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2022-10-13 11:10 +0200 |
| Message-ID | <jqq2vcFacj2U1@mid.individual.net> |
| In reply to | #86911 |
On 2022-10-13 at 10:02, Juha Nieminen wrote: > Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> wrote: >> So there you go: There are C++ compilers in use today in the year 2022 with CHAR_BIT something other than 8. > > The vast, *vast* majority of C and C++ programmers assume that 'char' is > always 8-bit, and sometimes write code making that assumption. It's > *extremely* rare to see any code out there that uses CHAR_BIT at all, > but it's quite common to see code that assumes that it's 8. Most C and > C++ programmers just assume that it's a de-facto universal standard, > and that the actual C and C++ standards are just antiquated in this > regard, by keeping "backwards compatibility" with some more exotic > CPUs from the 1970's that have been completely obsolete for decades. > > I suppose there's a good reason why the language standards don't assume > that 'char' is 8 bits, after all. Often you *can* make the assumption that you have 8-bit chars, and really not care about any other options. A lot of code will not run on a signal processor anyway, because it uses resources that are not available there, like a database or a desktop user interface.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-10-13 10:49 +0000 |
| Message-ID | <ti8qf8$155m$1@gioia.aioe.org> |
| In reply to | #86916 |
Bo Persson <bo@bo-persson.se> wrote: > On 2022-10-13 at 10:02, Juha Nieminen wrote: >> Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> wrote: >>> So there you go: There are C++ compilers in use today in the year 2022 with CHAR_BIT something other than 8. >> >> The vast, *vast* majority of C and C++ programmers assume that 'char' is >> always 8-bit, and sometimes write code making that assumption. It's >> *extremely* rare to see any code out there that uses CHAR_BIT at all, >> but it's quite common to see code that assumes that it's 8. Most C and >> C++ programmers just assume that it's a de-facto universal standard, >> and that the actual C and C++ standards are just antiquated in this >> regard, by keeping "backwards compatibility" with some more exotic >> CPUs from the 1970's that have been completely obsolete for decades. >> >> I suppose there's a good reason why the language standards don't assume >> that 'char' is 8 bits, after all. > > Often you *can* make the assumption that you have 8-bit chars, and > really not care about any other options. > > A lot of code will not run on a signal processor anyway, because it uses > resources that are not available there, like a database or a desktop > user interface. OTOH if you are making eg. a library that's supposed to be as standard-conforming and as portable as possible, you should start caring about CHAR_BIT, if your library somehow cares about bits, accesses bits, and cares about the sizes of types in bits. (Thinking about it, I have myself made some such libraries. I'll have to go and review them from this perspective, and make sure they don't make that assumption.)
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-10-13 12:05 +0000 |
| Message-ID | <ti8utu$1ed8$1@gioia.aioe.org> |
| In reply to | #86920 |
Juha Nieminen <nospam@thanks.invalid> wrote: > (Thinking about it, I have myself made some such libraries. I'll have > to go and review them from this perspective, and make sure they don't > make that assumption.) Interesting question: If you write a library that cares about bit sizes, and uses CHAR_BIT in order to not assume that 'char' has 8 bits, how would you write unit tests that check that the library works correctly with CHAR_BIT sizes other than 8?
[toc] | [prev] | [next] | [standalone]
| From | Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> |
|---|---|
| Date | 2022-10-13 06:34 -0700 |
| Message-ID | <06e0e319-0cee-44a3-a3f0-d1064e5ce5e7n@googlegroups.com> |
| In reply to | #86923 |
On Thursday, October 13, 2022 at 1:05:38 PM UTC+1, Juha Nieminen wrote: > > (Thinking about it, I have myself made some such libraries. I'll have > > to go and review them from this perspective, and make sure they don't > > make that assumption.) > Interesting question: If you write a library that cares about bit sizes, > and uses CHAR_BIT in order to not assume that 'char' has 8 bits, how would > you write unit tests that check that the library works correctly with > CHAR_BIT sizes other than 8? You go buy a Texas Instruments development board, upload your machine code, and communicate over RS232 to see if it's working. That's what I'm doing today.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-10-13 15:24 +0100 |
| Message-ID | <87a65zkdim.fsf@bsb.me.uk> |
| In reply to | #86923 |
Juha Nieminen <nospam@thanks.invalid> writes: > Juha Nieminen <nospam@thanks.invalid> wrote: >> (Thinking about it, I have myself made some such libraries. I'll have >> to go and review them from this perspective, and make sure they don't >> make that assumption.) > > Interesting question: If you write a library that cares about bit sizes, > and uses CHAR_BIT in order to not assume that 'char' has 8 bits, how would > you write unit tests that check that the library works correctly with > CHAR_BIT sizes other than 8? I don't think there's any automatic way[1]. But you can start by looking for places that directly or indirectly refer to 8 bit quantities: a literal 8, shifts of 7 or 3 places, constants like 0xff, 256 or 0400 and limits like 0xfe, 255 or 0377. The corresponding negative quantities should be searched for as well if signed char (or an assumed signed char) is being used. And of course you have to check that any uses of the macros CHAR_BIT and [SU]?CHAR_(MIN|MAX) are appropriate and don't suggest any unwarranted assumptions about their values. [1] Unless it's C code where some sort of 'lint' program might be able to help. I've not seen a lint-type program for C++... -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-10-13 15:59 +0200 |
| Message-ID | <ti95jj$1qbd8$1@dont-email.me> |
| In reply to | #86920 |
On 13/10/2022 12:49, Juha Nieminen wrote: > Bo Persson <bo@bo-persson.se> wrote: >> On 2022-10-13 at 10:02, Juha Nieminen wrote: >>> Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> wrote: >>>> So there you go: There are C++ compilers in use today in the year 2022 with CHAR_BIT something other than 8. >>> >>> The vast, *vast* majority of C and C++ programmers assume that 'char' is >>> always 8-bit, and sometimes write code making that assumption. It's >>> *extremely* rare to see any code out there that uses CHAR_BIT at all, >>> but it's quite common to see code that assumes that it's 8. Most C and >>> C++ programmers just assume that it's a de-facto universal standard, >>> and that the actual C and C++ standards are just antiquated in this >>> regard, by keeping "backwards compatibility" with some more exotic >>> CPUs from the 1970's that have been completely obsolete for decades. >>> >>> I suppose there's a good reason why the language standards don't assume >>> that 'char' is 8 bits, after all. >> >> Often you *can* make the assumption that you have 8-bit chars, and >> really not care about any other options. >> >> A lot of code will not run on a signal processor anyway, because it uses >> resources that are not available there, like a database or a desktop >> user interface. > > OTOH if you are making eg. a library that's supposed to be as > standard-conforming and as portable as possible, you should start > caring about CHAR_BIT, if your library somehow cares about bits, > accesses bits, and cares about the sizes of types in bits. > > (Thinking about it, I have myself made some such libraries. I'll have > to go and review them from this perspective, and make sure they don't > make that assumption.) It is very rare that "as portable as possible" is a realistic specification. It happens, but it is not common. Of course I don't recommend making assumptions about the target unless they are useful in some way, but there is no point in going out of your way to make code portable beyond any realistic targets. So if you need an eight bit variable, write "uint8_t" - if it turns out that your code gets used in unexpected places where CHAR_BIT is not 8, then at least there will be a clear compile-time failure. There's no point in going overboard in portability if it reduces the readability or efficiency of the code you are writing. As someone who has occasionally written code for 16-bit char devices (and worked alongside others who have used 32-bit char devices), I actually see it as an advantage that the code I generally write does /not/ compile on these devices. My code is not tested or checked on 16-bit char targets, and it is unlikely to be the most efficient code for such targets - if I or someone else wants to use the code on such systems, I'd rather they were forced to work through the code, checking it and re-writing as necessary, rather than just assuming it works because it compiles. If your code makes use of "char", or "uint8_t", or "uint_least8_t", or other types that are 8 bit on most targets, then it is likely that the code is not efficient on a 16-bit char DSP. You are likely to be wasting space (the first TMS320 device I used had about 300 bytes of ram in total - you do not waste 16-bit "bytes" to store a single character), are possibly getting different, unexpected and untested integral promotions, and could be failing to take advantage of the special features of the target. And if efficient code is not the goal, such DSP's are almost certainly not the best devices for the task in the first place. Sometimes there is a bit of shared code across such widely separated architectures - such as the OP's shared header. But most code for a DSP is written directly for the device.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-10-14 05:54 +0000 |
| Message-ID | <tiatim$68g$1@gioia.aioe.org> |
| In reply to | #86925 |
David Brown <david.brown@hesbynett.no> wrote: > It is very rare that "as portable as possible" is a realistic > specification. It happens, but it is not common. "Not common" does not mean "you shouldn't care", when you are writing a library that could potentially be used in more exotic architectures, such as the one mentioned in this thread. For example if you are writing, say, a small library that calculates hashes or checksums using a particular algorithm. It's not at all unrealistic that such a library could have uses in these more exotic microcontrollers (as microcontrollers are often used in embedded systems that handle data somehow, and might be interested in calculating things like checksums and hashes). And it is quite likely that such an algorithm might care about bit sizes.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2022-10-14 09:16 +0300 |
| Message-ID | <tiausq$21bt8$1@dont-email.me> |
| In reply to | #86947 |
14.10.2022 08:54 Juha Nieminen kirjutas: > David Brown <david.brown@hesbynett.no> wrote: >> It is very rare that "as portable as possible" is a realistic >> specification. It happens, but it is not common. > > "Not common" does not mean "you shouldn't care", when you are writing > a library that could potentially be used in more exotic architectures, > such as the one mentioned in this thread. > > For example if you are writing, say, a small library that calculates > hashes or checksums using a particular algorithm. It's not at all > unrealistic that such a library could have uses in these more exotic > microcontrollers (as microcontrollers are often used in embedded > systems that handle data somehow, and might be interested in calculating > things like checksums and hashes). And it is quite likely that such > an algorithm might care about bit sizes. True, but for really supporting such exotic platforms one would need to run tests on these platforms (or at least in an emulator) during the development and potentially also later if anything changes. Software without tests is just a work of literature. And testing for such exotic platforms might easily multiply the costs of the project by a large factor. That does not mean one should not attempt to write code in a reasonably generic way, but there are some limits.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-11-16 05:41 -0800 |
| Message-ID | <86r0y3c8yg.fsf@linuxsc.com> |
| In reply to | #86948 |
Paavo Helde <eesnimi@osa.pri.ee> writes: > 14.10.2022 08:54 Juha Nieminen kirjutas: > >> David Brown <david.brown@hesbynett.no> wrote: >> >>> It is very rare that "as portable as possible" is a realistic >>> specification. It happens, but it is not common. >> >> "Not common" does not mean "you shouldn't care", when you are writing >> a library that could potentially be used in more exotic architectures, >> such as the one mentioned in this thread. >> >> For example if you are writing, say, a small library that >> calculates hashes or checksums using a particular algorithm. It's >> not at all unrealistic that such a library could have uses in these >> more exotic microcontrollers (as microcontrollers are often used in >> embedded systems that handle data somehow, and might be interested >> in calculating things like checksums and hashes). And it is quite >> likely that such an algorithm might care about bit sizes. > > True, but for really supporting such exotic platforms one would need > to run tests on these platforms (or at least in an emulator) during > the development and potentially also later if anything changes. Perhaps some tests, but not necessarily all tests. Any parts of the program that are verifiably platform agnostic would not need platform-specific re-testing. Also, any platform-specific tests don't have to be run during development, but only just before the program is deployed on the exotic platforms in question, which could be significantly later than the original development. > Software without tests is just a work of literature. A hyperbolic statement if ever there was one.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-11-16 10:38 -0800 |
| Message-ID | <87mt8qkan0.fsf@nosuchdomain.example.com> |
| In reply to | #87415 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Paavo Helde <eesnimi@osa.pri.ee> writes:
>
>> 14.10.2022 08:54 Juha Nieminen kirjutas:
>>
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>
>>>> It is very rare that "as portable as possible" is a realistic
>>>> specification. It happens, but it is not common.
>>>
>>> "Not common" does not mean "you shouldn't care", when you are writing
>>> a library that could potentially be used in more exotic architectures,
>>> such as the one mentioned in this thread.
>>>
>>> For example if you are writing, say, a small library that
>>> calculates hashes or checksums using a particular algorithm. It's
>>> not at all unrealistic that such a library could have uses in these
>>> more exotic microcontrollers (as microcontrollers are often used in
>>> embedded systems that handle data somehow, and might be interested
>>> in calculating things like checksums and hashes). And it is quite
>>> likely that such an algorithm might care about bit sizes.
>>
>> True, but for really supporting such exotic platforms one would need
>> to run tests on these platforms (or at least in an emulator) during
>> the development and potentially also later if anything changes.
>
> Perhaps some tests, but not necessarily all tests. Any parts of
> the program that are verifiably platform agnostic would not need
> platform-specific re-testing. Also, any platform-specific tests
> don't have to be run during development, but only just before the
> program is deployed on the exotic platforms in question, which
> could be significantly later than the original development.
How do you know that a part of program is "verifiably platform agnostic"
without platform-specific testing? How else would that be verified?
>> Software without tests is just a work of literature.
>
> A hyperbolic statement if ever there was one.
Sure, but only slightly hyperbolic.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-12-05 11:42 -0800 |
| Message-ID | <86359t63ie.fsf@linuxsc.com> |
| In reply to | #87418 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Paavo Helde <eesnimi@osa.pri.ee> writes: >> >>> 14.10.2022 08:54 Juha Nieminen kirjutas: >>> >>>> David Brown <david.brown@hesbynett.no> wrote: >>>> >>>>> It is very rare that "as portable as possible" is a realistic >>>>> specification. It happens, but it is not common. >>>> >>>> "Not common" does not mean "you shouldn't care", when you are writing >>>> a library that could potentially be used in more exotic architectures, >>>> such as the one mentioned in this thread. >>>> >>>> For example if you are writing, say, a small library that >>>> calculates hashes or checksums using a particular algorithm. It's >>>> not at all unrealistic that such a library could have uses in these >>>> more exotic microcontrollers (as microcontrollers are often used in >>>> embedded systems that handle data somehow, and might be interested >>>> in calculating things like checksums and hashes). And it is quite >>>> likely that such an algorithm might care about bit sizes. >>> >>> True, but for really supporting such exotic platforms one would need >>> to run tests on these platforms (or at least in an emulator) during >>> the development and potentially also later if anything changes. >> >> Perhaps some tests, but not necessarily all tests. Any parts of >> the program that are verifiably platform agnostic would not need >> platform-specific re-testing. Also, any platform-specific tests >> don't have to be run during development, but only just before the >> program is deployed on the exotic platforms in question, which >> could be significantly later than the original development. > > How do you know that a part of program is "verifiably platform > agnostic" without platform-specific testing? How else would that > be verified? Testing can be used to show the presence of bugs, but never their absence. The same principle applies to determining whether code is platform agnostic. Showing that part of a program is platform agnostic can be done using formal methods and formal semantics, just like other kinds of formal verification. It can be more work to take into account the range of variation allowed by platform variability, but the principles involved are the same. >>> Software without tests is just a work of literature. >> >> A hyperbolic statement if ever there was one. > > Sure, but only slightly hyperbolic. On the contrary, more hyperbolic than most. That is the meaning of the sentence "a hyperbolic statement if ever there was one."
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2022-12-06 01:03 -0800 |
| Message-ID | <7f3d41f3-3fd5-4f66-9d7e-e5816f5f8933n@googlegroups.com> |
| In reply to | #87704 |
On Monday, 5 December 2022 at 21:43:08 UTC+2, Tim Rentsch wrote: > Keith Thompson <Keith.S.T...@gmail.com> writes: > > > Tim Rentsch <tr.1...@z991.linuxsc.com> writes: > > > >> Paavo Helde <ees...@osa.pri.ee> writes: > >> > >>> 14.10.2022 08:54 Juha Nieminen kirjutas: > >>> > >>>> David Brown <david...@hesbynett.no> wrote: > >>>> > >>>>> It is very rare that "as portable as possible" is a realistic > >>>>> specification. It happens, but it is not common. > >>>> > >>>> "Not common" does not mean "you shouldn't care", when you are writing > >>>> a library that could potentially be used in more exotic architectures, > >>>> such as the one mentioned in this thread. > >>>> > >>>> For example if you are writing, say, a small library that > >>>> calculates hashes or checksums using a particular algorithm. It's > >>>> not at all unrealistic that such a library could have uses in these > >>>> more exotic microcontrollers (as microcontrollers are often used in > >>>> embedded systems that handle data somehow, and might be interested > >>>> in calculating things like checksums and hashes). And it is quite > >>>> likely that such an algorithm might care about bit sizes. > >>> > >>> True, but for really supporting such exotic platforms one would need > >>> to run tests on these platforms (or at least in an emulator) during > >>> the development and potentially also later if anything changes. > >> > >> Perhaps some tests, but not necessarily all tests. Any parts of > >> the program that are verifiably platform agnostic would not need > >> platform-specific re-testing. Also, any platform-specific tests > >> don't have to be run during development, but only just before the > >> program is deployed on the exotic platforms in question, which > >> could be significantly later than the original development. > > > > How do you know that a part of program is "verifiably platform > > agnostic" without platform-specific testing? How else would that > > be verified? > > Testing can be used to show the presence of bugs, but never their > absence. The same principle applies to determining whether code > is platform agnostic. Showing that part of a program is platform > agnostic can be done using formal methods and formal semantics, > just like other kinds of formal verification. It can be more > work to take into account the range of variation allowed by > platform variability, but the principles involved are the same. > Formal proof of complex system is usually impossible as general solution is missing even to simple system of three point masses (three body problem). All platforms are way more complex than that ... yet made by fallible entities under time-to-market pressure. > >>> Software without tests is just a work of literature. > >> > >> A hyperbolic statement if ever there was one. > > > > Sure, but only slightly hyperbolic. > > On the contrary, more hyperbolic than most. That is the meaning of > the sentence "a hyperbolic statement if ever there was one." That hyperbole seems to be in our laws. All jurisdictions that I know of address copyrights of software as those of works of literature. So software that has not been tested to be useful for something is on general case just a work of literature written by author of it.
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.c++
csiph-web