Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Ian Collins <ian-news@hotmail.com>
Newsgroups: comp.lang.c++
Subject: Re: Examples of current platforms/architectures where sizeof(void*) >
Date: Tue, 14 Sep 2021 12:05:56 +1200
Lines: 59
Message-ID: <iqa7b4Fh2ruU6@mid.individual.net>
References: <sgglb9$c02$1@dont-email.me> <sh5bum$1s93$1@gioia.aioe.org> <sh7o2u$1f1k$1@gioia.aioe.org> <sh7v70$17kg$1@gioia.aioe.org> <sh85jr$1u8$1@dont-email.me> <sha37n$7s5$1@gioia.aioe.org> <shaaei$4aq$1@dont-email.me> <ipstvqFgmbiU3@mid.individual.net> <shbkec$rr9$1@dont-email.me> <ipt4vcFgmbiU4@mid.individual.net> <shck71$ctj$1@dont-email.me> <ipu5u5FgmbiU6@mid.individual.net> <shcrsh$19n$1@dont-email.me> <ipvdufFgmbiU7@mid.individual.net> <she43m$ssj$1@dont-email.me> <shf3f6$ulu$1@dont-email.me> <shf7db$td7$1@gioia.aioe.org> <shfgke$lvf$1@dont-email.me> <shgq1m$id4$1@dont-email.me> <shio80$rg$1@dont-email.me> <shj1l6$b41$1@dont-email.me> <iq4utmFh2ruU1@mid.individual.net> <shkk3o$hp$1@dont-email.me> <iq7lkaFh2ruU3@mid.individual.net> <shn7n4$ej5$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: individual.net 3bV7Lai5sHjtG55iOXMAzAFpVKO8/M1jFTn7wzQnnEXAfsPKXY
Cancel-Lock: sha1:9bf/yl6vcxklMmGuxSDZ/Xq3elk=
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
In-Reply-To: <shn7n4$ej5$1@dont-email.me>
Content-Language: en-US
Xref: csiph.com comp.lang.c++:81258

On 13/09/2021 22:03, Bart wrote:
> On 13/09/2021 01:51, Ian Collins wrote:
>> On 12/09/2021 22:17, Bart wrote:
> 
>>> Most of the stuff I do is not helped with unit tests.
>>
>> So it doesn't have any functions that can be tested?  That's a new on
>> one me!
>>
> You mean some tiny leaf function that has a well-defined task with a
> known range of inputs? That would be in the minority.

Doesn't every bit of well designed code have functions, leaf or 
otherwise, with well defined tasks?

> The problems I have to deal with are several levels above that and
> involve the bigger picture. A flaw in an approach might be discovered
> that means changes to global data structures and new or rewritten functions.
> 
> Also, if you're developing languages then you might have multiple sets
> of source code where the problem might lie.

So just use those for higher level testing.

<snip>

> Maybe unit tests could have applied to one of those sources, such as
> that C compiler, which might have inherent bugs exposed by the revised
> implementation language.

Unit tests apply to small "units" of code, such as classes or functions, 
not whole products.

>>> Where tshere are things that possibly be tested by ticking off entries in
>>> a list, you find the real problems come up with combinations or contexts
>>> you haven't anticipated and that can't be enumerated.
>>
>> If you find a problem, add a test fro it to prove that you have fixed it
>> and to make sure it does not recur.
> 
> My 'unit tests' for language products consist of running non-trivial
> applications to see if they still work.

Those aren't by any definition unit tests.  They are what would normally 
be know as acceptance tests.

> Or running multiple generations of a compiler.
> 
> So while I know that my C compiler bcc.exe can build Tiny C into tcc.exe
> and the result can build a range of C programs, if I take that tcc.exe
> and build Tiny C with it, that new tcc2.exe doesn't work (error in the
> generated binaries).
> 
> So where do you start with that?

By testing the logic in your code?

--
Ian.