Computing desk
< August 26	<< Jul \| August \| Sep >>	Current desk >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

August 27

Send email to Tim Cook

In the past days I sent email to Tim Cook for celebration of his 10 years in Apple. I wrote to tcook (at) apple.com but I don’t receive any answer. Sometime other people send mail to Tim Cook and receive answer. Is it the mail address wrong? --62.18.127.128 (talk) 06:18, 27 August 2021 (UTC)[reply]

In the past days he received 1,354,150 emails, but due to having to deal with other business, he has thus far only been able to answer 264,514 of them. Perhaps your message is one of the remaining 1,089,636. --Lambiam 09:02, 27 August 2021 (UTC)[reply]

Write to him using his real name, Tim Apple. :-) Bubba73 ^{You talkin' to me?} 05:22, 28 August 2021 (UTC)[reply]

yours words don’t answer to my question: is it the mail address wrong or not more in use? He have a new one? --62.18.127.128 (talk) 07:08, 28 August 2021 (UTC)[reply]

Wikipedia is an online encyclopaedia. We base our articles on published material. Email addresses are generally considered private, and we wouldn't have it. If you want to try to get into contact with Tim Cook, I suggest you do so via Apple. AndyTheGrump (talk) 07:21, 28 August 2021 (UTC)[reply]

Actually Tim Cook's email is public, as was the case of Steve Jobs' email. tcook at apple.com is the right email. --Bumptump (talk) 10:59, 29 August 2021 (UTC)[reply]

A posted hand written letter or card may be taken more seriously, and will stand out from the thousands of spammers. Graeme Bartlett (talk) 01:20, 29 August 2021 (UTC)[reply]

The higher-ups of many companies have an official email adress that conforms to the standard pattern of the company (for instance firstname.lastname@companywebsite.com). However, they do not read directly their inbox, they have a secretary who does that. Or possibly, an assistant’s secretary’s receptionary that filters the obvious spam, so that the assistant’s secretary can choose which emails require decisions to approve, and passes them on to the assistant who delivers a one-page five-bullet-point summary of today’s emails to the boss.

The chance that a congratulation email from some random employee (or even some random internet person) reaches the eyes of the CEO are vanishingly small, unless you put in something that interest the communication department (e.g. you are a little girl with late-stage cancer who really loves $COMPANY_VALUES and would like to have a $COMPANY_PRODUCT signed by the CEO before she passes away).

On a similar topic, emails addressed to politicians are almost never read by said politician, but they are in fact read by the politician’s assistant with some care and fairly often acted upon. At least for low to mid profile MPs in France, they actually get very few constituent emails. My source for this is an assistant that was the "first line of defense" of the inbox, and she said that once you exclude the political rants and insult letters (which are easy to filter out) it boils down to about 10 a week. Tigraan^{Click here for my talk page ("private" contact)} 16:21, 31 August 2021 (UTC)[reply]

Why would you have boolean types of different lengths?

Free Pascal has four boolean types; Boolean and ByteBool which are 8 bit synonyms, but also a 16 bit WordBool and a 32 bit LongBool[1]. What is the purpose of taking 32 bits for a Boolean? What advantage is there in having multiple Boolean types of different lengths in a high level language? -- Q Chris (talk) 08:10, 27 August 2021 (UTC)[reply]

In a short word: history. Back in 1983 all home micros and most small business machines were 8 bit. They were also critically short of memory, measured in KiB. There was no advantage to be gained in using more than a byte for storing booleans, indeed precious memory would be wasted. Turbo Pascal versions 1 & 2 (which was the fore-runner of FreePascal) only ran on ZX-80 processors. Memory fetches were all byte sized over an 8 bit bus. Over the years as first 16-bit and latterly 32-bit processors became available. Data is accessed over a 16-bit or 32-bit wide bus in 2 byte (word) and 4 byte (longword) chunks. However and particular byte can still be addressed by load-shift so there is no advantage at first glance in using the longer boolean for access reasons.

Consider now though if a particular chunk of memory stored a long integer, a boolean and a long float in that order. Furthermore assume that the integer starts at address 00000200. The boolean will be stored at 00000204 and the float at 00000205. both the integer and the boolean can be accessed in one memory read, but the float is now not aligned. To access it the longword at 00000204 is loaded, masked and shifted to get the first three bytes into the processor then the last byte is obtained by loading the longword at 00000208, mask, shift and place with the other three. In effect, double the work.

All data stored at higher addresses would now be misaligned unless, in due course, another odd three bytes are stored or padding introduced. In fact modern compilers should pad automatically so that in the case above the float would be stored at 00000208 leaving three unused bytes.

The subject is further discussed at Data_structure_alignment. HTH, Martin of Sheffield (talk) 08:51, 27 August 2021 (UTC)[reply]

Thanks, however in Pascal this appears to be redundant as they have the "packed" directive to determine whether types should be word aligned[2]. Without specifying "packed" then is an eight-bit value is followed by a float then filler bytes will be added. -- Q Chris (talk) 09:27, 27 August 2021 (UTC)[reply]

Hence "modern compilers should pad automatically". Indeed as the page you reference says "Without specifying packed, the compiler may insert extra unused bytes between members in order to align the data on full word boundaries for faster access by the CPU" (NB fullword = longword = 32 bit; word = 16 bit - again history). Consider though if you import an old routine that uses ByteBool, do you want it to crash or to simply pad silently? See Backward compatibility, in particular the sentence in §1.2 that says "Compiler backward compatibility may refer to the ability of a compiler of a newer version of the language to accept programs or data that worked under the previous version". Martin of Sheffield (talk) 11:48, 27 August 2021 (UTC)[reply]

Thanks, yes that makes sense -- Q Chris (talk) 13:20, 27 August 2021 (UTC)[reply]