Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #123613 > unrolled thread
| Started by | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| First post | 2017-11-29 10:41 -0800 |
| Last post | 2017-12-08 23:20 -0800 |
| Articles | 11 on this page of 71 — 13 participants |
Back to article view | Back to comp.lang.c
Some kind of contextual modulo operator? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-29 10:41 -0800
Re: Some kind of contextual modulo operator? jameskuyper@verizon.net - 2017-11-29 11:12 -0800
Re: Some kind of contextual modulo operator? bartc <bc@freeuk.com> - 2017-11-29 19:22 +0000
Re: Some kind of contextual modulo operator? bartc <bc@freeuk.com> - 2017-11-29 19:43 +0000
Re: Some kind of contextual modulo operator? jameskuyper@verizon.net - 2017-11-29 12:33 -0800
Re: Some kind of contextual modulo operator? bartc <bc@freeuk.com> - 2017-11-29 23:22 +0000
Re: Some kind of contextual modulo operator? jameskuyper@verizon.net - 2017-11-29 20:53 -0800
Re: Some kind of contextual modulo operator? bartc <bc@freeuk.com> - 2017-11-30 12:17 +0000
Re: Some kind of contextual modulo operator? bartc <bc@freeuk.com> - 2017-12-01 15:08 +0000
Re: Some kind of contextual modulo operator? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-01 07:31 -0800
Re: Some kind of contextual modulo operator? scott@slp53.sl.home (Scott Lurndal) - 2017-12-01 16:32 +0000
Re: Some kind of contextual modulo operator? bartc <bc@freeuk.com> - 2017-12-01 17:07 +0000
Re: Some kind of contextual modulo operator? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-01 09:15 -0800
Re: Some kind of contextual modulo operator? scott@slp53.sl.home (Scott Lurndal) - 2017-12-01 18:14 +0000
Re: Some kind of contextual modulo operator? bartc <bc@freeuk.com> - 2017-12-01 19:03 +0000
Re: Some kind of contextual modulo operator? scott@slp53.sl.home (Scott Lurndal) - 2017-12-01 20:54 +0000
Re: Some kind of contextual modulo operator? Keith Thompson <kst-u@mib.org> - 2017-12-01 12:09 -0800
Re: Some kind of contextual modulo operator? bartc <bc@freeuk.com> - 2017-12-01 21:56 +0000
Re: Some kind of contextual modulo operator? bartc <bc@freeuk.com> - 2017-12-01 23:11 +0000
Re: Some kind of contextual modulo operator? supercat@casperkitty.com - 2017-12-01 15:16 -0800
Re: Some kind of contextual modulo operator? David Brown <david.brown@hesbynett.no> - 2017-12-02 17:09 +0100
Re: Some kind of contextual modulo operator? bartc <bc@freeuk.com> - 2017-12-02 19:42 +0000
Re: Some kind of contextual modulo operator? Ian Collins <ian-news@hotmail.com> - 2017-12-03 09:16 +1300
Re: Some kind of contextual modulo operator? bartc <bc@freeuk.com> - 2017-12-02 22:06 +0000
Re: Some kind of contextual modulo operator? Ian Collins <ian-news@hotmail.com> - 2017-12-03 11:20 +1300
Re: Some kind of contextual modulo operator? bartc <bc@freeuk.com> - 2017-12-03 00:01 +0000
Re: Some kind of contextual modulo operator? Ian Collins <ian-news@hotmail.com> - 2017-12-03 13:55 +1300
Re: Some kind of contextual modulo operator? bartc <bc@freeuk.com> - 2017-12-03 02:14 +0000
Re: Some kind of contextual modulo operator? Ian Collins <ian-news@hotmail.com> - 2017-12-03 16:13 +1300
Re: Some kind of contextual modulo operator? bartc <bc@freeuk.com> - 2017-12-03 12:28 +0000
Re: Some kind of contextual modulo operator? bartc <bc@freeuk.com> - 2017-12-03 14:26 +0000
Re: Some kind of contextual modulo operator? Ian Collins <ian-news@hotmail.com> - 2017-12-04 10:49 +1300
Re: Some kind of contextual modulo operator? Ian Collins <ian-news@hotmail.com> - 2017-12-04 10:38 +1300
Re: Some kind of contextual modulo operator? bartc <bc@freeuk.com> - 2017-12-03 23:00 +0000
Re: Some kind of contextual modulo operator? Ian Collins <ian-news@hotmail.com> - 2017-12-04 12:10 +1300
Re: Some kind of contextual modulo operator? bartc <bc@freeuk.com> - 2017-12-03 23:33 +0000
Re: Some kind of contextual modulo operator? Ian Collins <ian-news@hotmail.com> - 2017-12-04 13:18 +1300
Re: Some kind of contextual modulo operator? bartc <bc@freeuk.com> - 2017-12-04 12:19 +0000
Re: Some kind of contextual modulo operator? Ian Collins <ian-news@hotmail.com> - 2017-12-05 07:58 +1300
Re: Some kind of contextual modulo operator? David Brown <david.brown@hesbynett.no> - 2017-12-04 00:30 +0100
Packed structs (was Re: Some kind of contextual modulo operator?) scott@slp53.sl.home (Scott Lurndal) - 2017-12-04 15:02 +0000
Re: Packed structs (was Re: Some kind of contextual modulo operator?) David Brown <david.brown@hesbynett.no> - 2017-12-04 16:34 +0100
Re: Packed structs (was Re: Some kind of contextual modulo operator?) Keith Thompson <kst-u@mib.org> - 2017-12-04 09:23 -0800
Re: Packed structs (was Re: Some kind of contextual modulo operator?) scott@slp53.sl.home (Scott Lurndal) - 2017-12-04 18:31 +0000
Re: Packed structs (was Re: Some kind of contextual modulo operator?) supercat@casperkitty.com - 2017-12-04 15:37 -0800
Re: Some kind of contextual modulo operator? supercat@casperkitty.com - 2017-12-04 08:39 -0800
Re: Some kind of contextual modulo operator? "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2017-12-03 18:13 -0800
Re: Some kind of contextual modulo operator? Ian Collins <ian-news@hotmail.com> - 2017-12-03 14:50 +1300
Re: Some kind of contextual modulo operator? scott@slp53.sl.home (Scott Lurndal) - 2017-12-04 15:00 +0000
Re: Some kind of contextual modulo operator? bartc <bc@freeuk.com> - 2017-12-04 15:53 +0000
Re: Some kind of contextual modulo operator? scott@slp53.sl.home (Scott Lurndal) - 2017-12-04 18:26 +0000
Re: Some kind of contextual modulo operator? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-04 10:34 -0800
Re: Some kind of contextual modulo operator? David Brown <david.brown@hesbynett.no> - 2017-12-03 19:40 +0100
Re: Some kind of contextual modulo operator? David Kleinecke <dkleinecke@gmail.com> - 2017-12-03 11:35 -0800
Re: Some kind of contextual modulo operator? scott@slp53.sl.home (Scott Lurndal) - 2017-12-04 14:59 +0000
Re: Some kind of contextual modulo operator? Keith Thompson <kst-u@mib.org> - 2017-12-01 08:56 -0800
Re: Some kind of contextual modulo operator? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-01 08:58 -0800
Re: Some kind of contextual modulo operator? scott@slp53.sl.home (Scott Lurndal) - 2017-12-01 18:16 +0000
Re: Some kind of contextual modulo operator? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-01 10:28 -0800
Re: Some kind of contextual modulo operator? David Brown <david.brown@hesbynett.no> - 2017-12-01 20:19 +0100
Re: Some kind of contextual modulo operator? Gareth Owen <gwowen@gmail.com> - 2017-12-01 22:22 +0000
Re: Some kind of contextual modulo operator? jameskuyper@verizon.net - 2017-12-01 07:49 -0800
Re: Some kind of contextual modulo operator? bartc <bc@freeuk.com> - 2017-12-01 16:54 +0000
Re: Some kind of contextual modulo operator? jameskuyper@verizon.net - 2017-12-01 09:34 -0800
Re: Some kind of contextual modulo operator? bartc <bc@freeuk.com> - 2017-12-01 18:48 +0000
Re: Some kind of contextual modulo operator? jameskuyper@verizon.net - 2017-12-01 11:27 -0800
Re: Some kind of contextual modulo operator? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-29 12:17 -0800
Re: Some kind of contextual modulo operator? bartc <bc@freeuk.com> - 2017-11-30 12:27 +0000
Re: Some kind of contextual modulo operator? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-30 06:11 -0800
Re: Some kind of contextual modulo operator? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-11-29 15:02 -0500
Some kind of contextual modulo operator? mcheung63@gmail.com - 2017-12-08 23:20 -0800
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-12-01 22:22 +0000 |
| Message-ID | <87mv32ccml.fsf@gmail.com> |
| In reply to | #123677 |
Keith Thompson <kst-u@mib.org> writes: > I understand that calling malloc() as a foreign function is more > complicated than calling it from C. I don't understand why you'd > deliberately use a signed argument for a function that takes an unsigned > argument. That would be because, as he's repeatedly demonstrated, he's not very bright
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-12-01 07:49 -0800 |
| Message-ID | <ebb681a2-4f29-49be-a406-b9cc25da62ef@googlegroups.com> |
| In reply to | #123633 |
On Thursday, November 30, 2017 at 7:17:39 AM UTC-5, Bart wrote: > On 30/11/2017 04:53, jameskuyper@verizon.net wrote: > > On Wednesday, November 29, 2017 at 6:22:28 PM UTC-5, Bart wrote: > >> On 29/11/2017 20:33, jameskuyper@verizon.net wrote: > > >>> you have an incorrect understanding of what it > >>> should do. > > >>> You insist on using compilers in their default mode > > > If you understood the relevant rules > > > that means you don't understand those rules. > > Not judgemental much are you? You're right, I'm not very judgemental - only when it's appropriate, as in these cases. You really do deal with C in the most bizarre and unproductive fashion. I was going to end that sentence with "that I could imagine", but when I thought about it I realized that if I'd never read any of your messages, my imagination would not have been flexible enough to imagine someone taking your approach to C. I can imagine someone hating C as much as you do, and misunderstanding it as badly as you do - but to then insist on programming in it anyway, and then complaining about it the way you do is just ridiculous.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-01 16:54 +0000 |
| Message-ID | <aPfUB.50931$UP1.44448@fx31.am4> |
| In reply to | #123673 |
On 01/12/2017 15:49, jameskuyper@verizon.net wrote: > On Thursday, November 30, 2017 at 7:17:39 AM UTC-5, Bart wrote: >> On 30/11/2017 04:53, jameskuyper@verizon.net wrote: >>> On Wednesday, November 29, 2017 at 6:22:28 PM UTC-5, Bart wrote: >>>> On 29/11/2017 20:33, jameskuyper@verizon.net wrote: >> >>>>> you have an incorrect understanding of what it >>>>> should do. >> >>>>> You insist on using compilers in their default mode >> >>> If you understood the relevant rules >> >>> that means you don't understand those rules. >> >> Not judgemental much are you? > > You're right, I'm not very judgemental - only when it's appropriate, as in these > cases. You really do deal with C in the most bizarre and unproductive fashion. The most productive period of my life for coding was when I wasn't using C, at a time when it was de rigueur for the sort of work I was doing, if people didn't want to use assembly. I vaguely knew about 'compile times', 'link-times' and 'build-times' being an issue for other people, but that was NEVER a problem for me because I don't use other people's inefficient tools. Even now, if I have to create a program for a machine which I can't support natively and have to go through C and a C compiler, it is FAR more productive to code and develop in my own language, and pass generated C through a C compiler to get a production version. At that point, I DON'T CARE what options are given to that C compiler, which is compiling working code anyway, other then the basics such as -O3 and -m64. It's more productive because I can write 'ref proc' instead of gobbledygook like 'void(*)(void)', or having to deal with half a century's worth of baggage. th "that I could imagine", but when I thought > about it I realized that if I'd never read any of your messages, my imagination > would not have been flexible enough to imagine someone taking your approach to > C. I can imagine someone hating C as much as you do, and misunderstanding it as > badly as you do - but to then insist on programming in it anyway, I 'program' in it partly because I have to for interfacing reasons, also because it's the nearest low-level mainstream language to my own when needing to use an intermediate language, and conveniently has ubiquitous implementations. And, although I realise it irks you to admit this, I actually understand it quite well. That's not the same as liking it. and then > complaining about it the way you do is just ridiculous. What complaint have I made about it in this thread? I mentioned that your suggested alternative for the OP's task didn't do the same job, and gave odd results just below zero (because divide ops in C are symmetrical around zero although the function you want really needs to be asymmetric). You decided to turn that into a personal attack, and assumed I had no idea what was going on.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-12-01 09:34 -0800 |
| Message-ID | <c24eb661-1fb3-43c3-8874-856d81b08c32@googlegroups.com> |
| In reply to | #123676 |
On Friday, December 1, 2017 at 11:54:48 AM UTC-5, Bart wrote: ... > And, although I realise it irks you to admit this, I actually understand > it quite well. That's not the same as liking it. The way you wrote that message, it implies that it's something I have in fact admitted, which is not the case. You should have used the subjunctive mood: "... I realize that it would irk you to admit it, ...". Virtually every message you post to this newsgroup conveys a misunderstanding of C. Merely disliking C would be far less of a problem. But you routinely misrepresent C in ways that reflect the fact that you don't like it. I'm giving you the benefit of the doubt when I assume that those mis-representations correctly reflect your own misunderstandings. If you deliberately mis-represented something you correctly understood, that would be outright lying.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-01 18:48 +0000 |
| Message-ID | <vthUB.82068$Yt.66253@fx36.am4> |
| In reply to | #123682 |
On 01/12/2017 17:34, jameskuyper@verizon.net wrote:
> On Friday, December 1, 2017 at 11:54:48 AM UTC-5, Bart wrote:
> ...
>> And, although I realise it irks you to admit this, I actually understand
>> it quite well. That's not the same as liking it.
>
> The way you wrote that message, it implies that it's something I have in fact admitted, which is not the case. You should have used the subjunctive mood: "... I realize that it would irk you to admit it, ...".
>
> Virtually every message you post to this newsgroup conveys a misunderstanding of C.
I think you have a bee in your bonnet about people misusing English as well.
>Merely disliking C would be far less of a problem. But you routinely misrepresent C in ways that reflect the fact that you don't like it.
I suppose you will claim that my frequent 'misunderstanding' couldn't
possibly be due to C /being/ easy to misunderstand.
Here's an example:
(******************printf)("Hello world");
This is perfectly valid C code, and it works without errors.
I complain about the fact that it allows all those extra asterisks,
which can mask genuine misunderstandings about a piece of code, or can
give a misleading idea about the number of function pointer levels that
are in use. It also behaves differently from array and struct pointers
where the number of derefs have to be spot-on.
Invariably is it down to Bart not understanding C, or not using the
right tools, rather than it being an undesirable quirk of C which is
down to how it was designed.
And this is the same for every observation I make.
Guys, you need to be able to take criticism for /your/ language.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-12-01 11:27 -0800 |
| Message-ID | <b09cd61a-e3af-4670-bc92-7759ac5b76ea@googlegroups.com> |
| In reply to | #123686 |
On Friday, December 1, 2017 at 1:48:14 PM UTC-5, Bart wrote:
> On 01/12/2017 17:34, jameskuyper@verizon.net wrote:
> > On Friday, December 1, 2017 at 11:54:48 AM UTC-5, Bart wrote:
> > ...
> >> And, although I realise it irks you to admit this, I actually understand
> >> it quite well. That's not the same as liking it.
> >
> > The way you wrote that message, it implies that it's something I have in
> > fact admitted, which is not the case. You should have used the subjunctive
> > mood: "... I realize that it would irk you to admit it, ...".
...
> I think you have a bee in your bonnet about people misusing English as well.
Misusing any language, whether a natural language or a computer language, can lead to unnecessary confusion; computer languages have less redundancy, which can make the consequences of such confusion much worse. If that fact bothers me more than it does you, I'll happily accept that statement as the compliment that it was not intended to be.
> > Merely disliking C would be far less of a problem. But you routinely
> > misrepresent C in ways that reflect the fact that you don't like it.
>
> I suppose you will claim that my frequent 'misunderstanding' couldn't
> possibly be due to C /being/ easy to misunderstand.
Oh, it's not the easiest language in the world to understand. However, it's
nowhere near as difficult as you claim it to be. A language that difficult to
understand would only be used for niche applications by a small dedicated cult
of masochists. It wouldn't be one of the most widely implemented languages in
the world, and it wouldn't have anywhere near as much new code being written for
it as C actually has. And before you try to claim that this is exactly the case,
such a language would not be so widely used that you would feel compelled to use
it, due to a lack of acceptable alternatives.
> Here's an example:
>
> (******************printf)("Hello world");
>
> This is perfectly valid C code, and it works without errors.
>
> I complain about the fact that it allows all those extra asterisks,
> which can mask genuine misunderstandings about a piece of code, or can
> give a misleading idea about the number of function pointer levels that
> are in use. It also behaves differently from array and struct pointers
> where the number of derefs have to be spot-on.
C doesn't require all of those extra asterisks, and no one sane puts in more
than the minimum needed (some people put in the minimum number that was needed
under the old rules, which is sometimes larger than the minimum number currently
needed). As a result, in reality, this feature causes far less confusion than
you think it does. This feature was developed to simplify the use of function
pointers, and it does achieve that goal, but I'm not sure it was a good idea.
> Invariably is it down to Bart not understanding C, or not using the
> right tools, rather than it being an undesirable quirk of C which is
> down to how it was designed.
>
> And this is the same for every observation I make.
>
> Guys, you need to be able to take criticism for /your/ language.
I don't own the language, I just use it. I understand why it has a number of undesirable features, and I understand why it's not feasible to fix all (or even most) of them - a proper respect for the need to be backwards compatible with existing code being the main reason for features that I disapprove of, but which
cannot be fixed. But those features are not anywhere near as difficult to deal
with as you make them out to be, and they cause nowhere near as many problems
for people who bother understanding them as they do for you. And that is why
insisting on using the language while refusing to understand it is in fact
behavior that deserves to be criticized.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-11-29 12:17 -0800 |
| Message-ID | <f31884c8-9c35-4ff3-8c82-50aadae99ca4@googlegroups.com> |
| In reply to | #123619 |
On Wednesday, November 29, 2017 at 2:22:40 PM UTC-5, Bart wrote: > On 29/11/2017 19:12, jameskuyper@verizon.net wrote: > > On Wednesday, November 29, 2017 at 1:41:43 PM UTC-5, Rick C. Hodgin wrote: > >> Is there some natural way in C to do this (without a macro): > >> > >> // Round up to the next largest 16-byte border > >> char *p = malloc((some_value + 16) & ~0xf); > > > > 16*((some_value+15)/16) > > This gives different results (see below). Which is right depends on > whether you want a value that is already a multiple of 16 to be rounded > up. I think usually you don't. In this particular case, always rounding up to provide at least one additional byte (so even if it's paragraph aligned, it still needs at least one more, so it goes up a full 16), but for other operations it could just go up to the next highest paragraph boundary, which it may already be sitting at. This came about for a memory algorithm I was working on today. It needed some padding. As I was coding the & ~0xf solution, it just occurred to me that +% and -% operators would be useful in such cases. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-11-30 12:27 +0000 |
| Message-ID | <GOSTB.79441$Am1.7798@fx23.am4> |
| In reply to | #123623 |
On 29/11/2017 20:17, Rick C. Hodgin wrote: > On Wednesday, November 29, 2017 at 2:22:40 PM UTC-5, Bart wrote: >> On 29/11/2017 19:12, jameskuyper@verizon.net wrote: >>> On Wednesday, November 29, 2017 at 1:41:43 PM UTC-5, Rick C. Hodgin wrote: >>>> Is there some natural way in C to do this (without a macro): >>>> >>>> // Round up to the next largest 16-byte border >>>> char *p = malloc((some_value + 16) & ~0xf); >>> >>> 16*((some_value+15)/16) >> >> This gives different results (see below). Which is right depends on >> whether you want a value that is already a multiple of 16 to be rounded >> up. I think usually you don't. > > In this particular case, always rounding up to provide at least one > additional byte What's the byte for, adding a zero-terminator to a counted string? (so even if it's paragraph aligned, it still needs at > least one more, so it goes up a full 16), but for other operations it > could just go up to the next highest paragraph boundary, which it may > already be sitting at. > > This came about for a memory algorithm I was working on today. It > needed some padding. As I was coding the & ~0xf solution, it just > occurred to me that +% and -% operators would be useful in such cases. I'm sure you know C well enough to realise there are no such operators! I know you have a thing about macros, but what about an inline function? (Or even a non-inlined one, if the result is going to used with functions anyway.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-11-30 06:11 -0800 |
| Message-ID | <cbb20085-4b11-4bed-9aa9-76f46351d6a0@googlegroups.com> |
| In reply to | #123634 |
On Thursday, November 30, 2017 at 7:27:29 AM UTC-5, Bart wrote: > On 29/11/2017 20:17, Rick C. Hodgin wrote: > > On Wednesday, November 29, 2017 at 2:22:40 PM UTC-5, Bart wrote: > >> On 29/11/2017 19:12, jameskuyper@verizon.net wrote: > >>> On Wednesday, November 29, 2017 at 1:41:43 PM UTC-5, Rick C. Hodgin wrote: > >>>> Is there some natural way in C to do this (without a macro): > >>>> > >>>> // Round up to the next largest 16-byte border > >>>> char *p = malloc((some_value + 16) & ~0xf); > >>> > >>> 16*((some_value+15)/16) > >> > >> This gives different results (see below). Which is right depends on > >> whether you want a value that is already a multiple of 16 to be rounded > >> up. I think usually you don't. > > > > In this particular case, always rounding up to provide at least one > > additional byte > What's the byte for, adding a zero-terminator to a counted string? Yes. :-) It's a debug marker I'm using right now. It's actually already padded before and after with 16 bytes as well, but they are non-\000, so this one acts as a stop-print for debugging. > (so even if it's paragraph aligned, it still needs at > > least one more, so it goes up a full 16), but for other operations it > > could just go up to the next highest paragraph boundary, which it may > > already be sitting at. > > > > This came about for a memory algorithm I was working on today. It > > needed some padding. As I was coding the & ~0xf solution, it just > > occurred to me that +% and -% operators would be useful in such cases. > > I'm sure you know C well enough to realise there are no such operators! I think I do, but I find myself learning new things about C regularly. Mostly obscure or seldom-used things, but just the other day I learned about the ++ operator, so there's still room for me to grow. :-) > I know you have a thing about macros, but what about an inline function? It's not macros I have an issue with, it's their syntax in code. I think macros are excellent. But in cases where something is oft-used, it should have a real operator. That's my position. > (Or even a non-inlined one, if the result is going to used with > functions anyway.) You receive a lot of flak in this group, but I want you to know I think most of your positions on things are spot on. It's a divided mindset at work between people who think one way, and people who think another way. I see the division very prevalent in the GNU group, and the older developers who learned rigid methodologies, compared to those I would consider to be better thinkers, more creative in their approaches to code. The rigid group is unwilling to adapt and move to meet a thought where it should be met. It's sometimes sad to see honestly. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-11-29 15:02 -0500 |
| Message-ID | <4151e1b9-22eb-ff7c-cdb2-1d10c8caa647@verizon.net> |
| In reply to | #123617 |
On 11/29/2017 02:12 PM, jameskuyper@verizon.net wrote:
> On Wednesday, November 29, 2017 at 1:41:43 PM UTC-5, Rick C. Hodgin wrote:
>> Is there some natural way in C to do this (without a macro):
>>
>> // Round up to the next largest 16-byte border
>> char *p = malloc((some_value + 16) & ~0xf);
>
> 16*((some_value+15)/16)
I had assumed that the behavior of your code when some_value is already
a multiple of 16 was an error on your part, and that it's failure to
handle that case correctly was the reason for your message.
Bart's message made me realize it might have been intentional. In that
case, your code as written is fairly natural. If you don't like it for
some reason, you should explain that reason, so we can choose the right
alternative. I would have written
16*(1 + some_value/16)
but I can't claim it has any great virtue compared to your version. I
find it easier to understand, but that's because you seem to be thinking
in terms of bit patterns, while I tend to think in terms of values.
Note: the constant 0xf has a type of int, and therefore so does ~0xf.
This would produce the wrong result if some_value+16 > INT_MAX.
[toc] | [prev] | [next] | [standalone]
| From | mcheung63@gmail.com |
|---|---|
| Date | 2017-12-08 23:20 -0800 |
| Message-ID | <7513bd2a-28f5-45ed-9aaa-0865c10b277c@googlegroups.com> |
| In reply to | #123613 |
this fucking asshole is called rick c. hodgin, this asshole keep spamming newsgroup alt.os.development and comp.lang.c++. God has punished his mother to die by cancer. She is in hell now.
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c
csiph-web