Computing desk
< September 29	<< Aug \| September \| Oct >>	October 1 >

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

September 30

Spelling

When I type in the edit box on Wikipedia, words which either my pc or Wikipedia thinks are misspelt get underlined in red, or sometimes silently changed to the wrong spelling. (Usually, from English to American). If I right-click on the redlined word I get offered American spellings, but the language setting (in the little box that comes up) is for United Kingdom English. So - is this my pc or is it Wikipedia doing this? And, how do I stop it? It's very annoying, especially when it silently introduces the incorrect spelling. Thanks. DuncanHill (talk) 02:31, 30 September 2014 (UTC)[reply]

I think it's neither your PC nor Wikipedia but your browser. When you right-click on a red-underlined word there should be a submenu where you can select a dictionary ("Languages" in Firefox, "Spell-checker options" in Chrome). If UK English is selected there, but you're getting US English spelling suggestions, then I'm stumped. -- BenRG (talk) 05:47, 30 September 2014 (UTC)[reply]

Possibly words have been added to the original dictionary. In many browsers, it's also possible to remove words so that spellings from the wrong version of English do not appear (though it would be quicker to revert to the original correct dictionary). It's rather annoying that each different browser on each computer I use has its own dictionary. Does anyone know a way to point them all to one dictionary so that I don't have to keep teaching each of them correct spellings? (I suspect that it's not possible because they each use a different system.) Dbfirs 07:41, 30 September 2014 (UTC)[reply]

For Firefox, you need to add the British English dictionary by Right-Click->Languages->Add Dictionaries. You then need to change this to the default, I think that's by |Right-Click->Languages again. CS Miller (talk) 09:08, 30 September 2014 (UTC)[reply]

Thanks - I use IE11, as I said, it's set to British English, and I would never have asked it to remember American spellings. DuncanHill (talk) 14:13, 30 September 2014 (UTC)[reply]

I agree with Ben, that it is the browser, and it seems then that IE doesn't really support BrEng properly. It could be that the language setting you've ticked only applies to menu items and not spelling. I'd recommend searching around for information about how to change dictionary behaviours in IE11; this might help [1]. Failing that, I recommend changing to a browser that properly supports your needs. My favourites are the ones with more colour in the icon, e.g. Chrome or Firefox ;) SemanticMantis (talk) 16:01, 30 September 2014 (UTC)[reply]

As far as I can see every setting possible is to British English. I only seem to get this behaviour in the edit window on Wikipedia - not in the edit summary box, and not on other websites. I don't wish to change to another browser just for Wikipedia. DuncanHill (talk) 16:39, 30 September 2014 (UTC)[reply]

I can reproduce this with IE 11 on US-English Windows 7. If I make "English (United Kingdom)" my default dictionary, it still treats color as correct and colour as misspelled. Additional dictionaries can be installed from Tools → Manage add-ons → Spelling Correction, but "English" is treated as a single dictionary language that is already installed. What's really bizarre is that I can't find any mention of this bug online, except this thread (with no solution) from someone who apparently had the same problem way back in IE 9. It must work for most people, otherwise it would have been fixed by now. Are you also running a non-UK version of Windows?

I suppose you could disable that add-on and use a third-party spell-checking add-on like ieSpell. -- BenRG (talk) 20:30, 30 September 2014 (UTC)[reply]

I figured it out: Wikipedia's edit box has a lang="en" attribute, and IE is treating that as en-US, overriding the dictionary choice. I don't know what to do about it, though. It seems like a bug in IE, not MediaWiki, although the spec is so vague that I'm not sure. At the least it's clearly an IE bug that "English (United Kingdom)" remains selected in the Language submenu and you can't even override it. Maybe if you report it to Microsoft they'll fix it someday. -- BenRG (talk) 20:54, 30 September 2014 (UTC)[reply]

UK version of everything on my PC as far as I can tell! I have a vague memory that plain "en" for language always means American. Anyway - thank you all for trying! DuncanHill (talk) 20:59, 30 September 2014 (UTC)[reply]

I can't find anything in BCP 47 suggesting that en-US is a default. It does say that individual users could define language priority lists to be used for defaulting. But even if I make en-GB my preferred language in Internet Options → Languages, it still chooses en-US. -- BenRG (talk) 21:13, 30 September 2014 (UTC)[reply]

Try Compatibility View. -- Gadget850^talk 21:23, 30 September 2014 (UTC)[reply]

There's no difference (and I wouldn't expect one since this doesn't seem to be a backward-compatibility issue). -- BenRG (talk) 22:08, 30 September 2014 (UTC)[reply]

addition of addresses in C

its a question i was asked in an interview and about its logic.though i got the answer right but i couldnt figure the logic. the question is

#include<stdio.h>
void main()
{
    int a;
    a=0x000 + 0x050;
    printf("%d",a);
}

this code prints the value of a as 80; but for a=0x000+0x010; the value of a is 16; thanks in advance.223.176.243.204 (talk) 07:10, 30 September 2014 (UTC)[reply]

Those are not "addresses"; they are just integers written in base 16. Normal arithmetic applies, and by using %d you asked for the output to be in base 10.

Your example is only adding integers - they aren't addresses (although they might be integers that represent addresses - although I doubt it). True address arithmetic is weird in C and C++. Adding two addresses is meaningless...and it's an error to try to do it in C or C++:

    int x = 0 ;
    int y = 0 ;
    int *z = &x + &y ;
    printf ( "%p\n", z ) ;

..produces "error: invalid operands to binary expression" in gcc....and the type of 'z' is kinda dubious too! You can convert addresses into regular integers and add them - but not directly. What you can meaningfully and legally do is to subtract addresses from one from the other:

   int x = 0 ;
   int y = 0 ;
   int z = &x - &y ;
   printf ( "%d\n", z ) ;

It's kinda useless in that example but consider something like:

 char *str = "HelloWorld" ;
 char *p = strstr ( str, "World" ) ;  // returns a pointer to the 'W' inside str
 char *q = strstr ( str, "Hell" ) ;     // returns a pointer to the 'H' inside str
 int x = *p - *q ;

...actually calculates the length of the word "Hello" by subtracting the address of the 'H' from the address of the 'W'.

Beware though, address arithmetic divides the result by sizeof the type of the pointers...which can result in some considerably odd things happening:

  int *x = (int *) 100 ;
  int *y = (int *) 200 ;
  int z = y - x ;
  printf ( "%d\n", z ) ;

prints 25, and not 100 as you might naively expect! SteveBaker (talk) 15:12, 3 October 2014 (UTC)[reply]

By the way, writing "void main" is an error, though it's common enough in practice that C implementations typically let you get away with it. --65.94.51.64 (talk) 09:02, 30 September 2014 (UTC)[reply]

While the above is fully correct, it's much better stated as 'By the way, writing "void main" is an error'. ;-) --Stephan Schulz (talk) 18:21, 30 September 2014 (UTC)[reply]

It's not necessarily an error, it's just not strictly conforming. It is conforming if the implementation is documented as supporting it (WG14/N1124 §5.1.2.2.1.1). That said, you should never write void main because it's less portable, it may have undefined behavior on implementations that don't support it, and it's totally useless. It doesn't even save you from having to write return 0; at the end because that's unnecessary anyway ("reaching the } that terminates the main function returns a value of 0" — WG14/N1124 §5.1.2.2.3). (edit: That's true in C99 and C++, but not in C89. Many compilers, including gcc, still default to C89 after all these years, so you may still need to put return 0; at the end of your main function in C.) -- BenRG (talk) 22:04, 30 September 2014 (UTC)[reply]

While the above is fully correct, it's much better stated as 'By the way, writing "void main" is an error'. ;-) --Stephan Schulz (talk) 18:21, 30 September 2014 (UTC)[reply]

No, it's better to explain the reasons. That's what teaching is. People tend to ignore seemingly arbitrary and unexplained rules, and for good reason, I think. -- BenRG (talk) 16:53, 1 October 2014 (UTC)[reply]

Why do you need to spoil a perfectly good joke only to be reasonable? --Stephan Schulz (talk) 05:51, 2 October 2014 (UTC)[reply]

I may be wrong, but I was told many compilers automatically converted void main to int main anyways. --Wirbelwind(ヴィルヴェルヴィント) 20:14, 2 October 2014 (UTC)[reply]

Many compilers certainly accept it. But, as Ben pointed out, it's not portable. It hides from the reader the knowledge that yes, a C program can return a status to the environment - and that is usually a good thing, especially if programs are composed into larger systems. --Stephan Schulz (talk) 13:49, 3 October 2014 (UTC)[reply]

To which, I say "exit (status)"! The problem with void main() being illegal is that some programs are intended never to terminate - or to terminate via 'exit()' or perhaps to run in an environment where returning from main is actually undefined behavior in the first place (imagine you are running your program on the bare metal in an embedded computer). In practice, it doesn't cost much to stick a 'return 0;' onto the end of a program that never returns - but if every byte of memory counts - then it's kinda wasteful to have to zero out the R0 register in an instruction that's never reached. Many of my C++ programs have a main that ends with 'assert(false)'. However, I can also see that in the larger scheme of things, it might be necessary in some imaginary future implementation that the operating system be able to know that the main function reliably returns an integer...but it does seem a bit of a wash to me...especially because we have systems like Microsoft Windows where the function that the operating system calls may be named "winmain" and not "main" in the first place. A more logical thing would have been (way back in the days of C) to state that the function that the operating system calls is provided to the linker - rather than being the only function name that has a 'reserved' name. But it is what it is - and I don't think people should continue to use 'void main' in defiance of the standard. SteveBaker (talk) 14:47, 3 October 2014 (UTC)[reply]