HN user

johnny-lee

3 karma
Posts0
Comments10
View on HN
No posts found.

Try giving your kids xylitol candies/mints (available at amazon and many health food stores), initially after every meal - you can probably reduce the frequency/amount later.

There are xylitol chewing gum, but I've read articles about kids dislike for chewing gum these days - so candies/mints may be more palatable.

search for "xylitol tooth decay" for explanation about its effects.

Excerpts from one such link: https://bellharbourdental.com/cavities/xylitol-reverse-tooth...

Mutans streptococci (MS or S. mutans) are a bacterium in plaque and saliva that are major contributors to tooth decay and oral disease.

...xylitol reduces the levels of MS in the mouth. It essentially starves the MS bacterium by not providing any energy to it when metabolized. Since xylitol is a non-nutritive sugar the MS bacteria spend energy to metabolize it and in return receive no energy gain from it. It’s a sunken cost and the S. mutans cannot keep growing. This reduces the population of S. mutans and impedes the ability of plaque and bacteria to adhere to our teeth. It also decreases the amount of lactic acid present in our mouth, making our teeth less vulnerable to decay. Curiously xylitol does all of this without affecting the other beneficial, or overall, flora of our mouths.

Another amazing find has been that when a mother of a newborn uses xylitol, that child’s teeth prove to be more resilient against cavities as they develop. Children have a dramatically lower risk of cavities when their mothers use xylitol starting 3-6 months after childbirth and continue using it until all their baby teeth are formed around the age of 2.

Xylitol comes in many forms but the most common delivery method is through chewing gum. Chewing xylitol gum for 3 weeks or more provides not only short but also long-term reductions in S. mutans levels! Even just the action of chewing the gum helps to rinse away lactic acids.

In order to be effective against bacteria the optimal intake levels are at least 6-10g of xylitol per day. Xylitol gums range from having .75g – 1g of xylitol per piece. So make sure to check the gum that you’re buying to make sure it contains closer to the ~1g/piece mark. In order to reach those levels you will need to chew more than one piece at a time a few times a day. After meals is a great routine to get into, but make sure to wait for at least 20 minutes after eating food before chewing xylitol gum.

That's what scares a lot of people when they run a static analyzer on code for the first time - all the possible problems.

Some of the possible problems are easy to confirm or deny just by looking at one line of code, but others will require much more analysis.

You need a tool/viewer to show the possible problem and what caused the possible problem. Such a tool improves the user experience dealing with static analyzer results.

see the wikipedia entry on Chinese numerology, esp. number 9.

https://en.wikipedia.org/wiki/Chinese_numerology#Nine

tl;dr - Chinese pronunciation of 9 sounds similar to the Chinese word for longevity/long life.

You'd rarely see the number 4 used since that sounds like the pronunciation for the word 'death'.

8 is another popular number, synonymous with wealth.

Go into a parking lot with many Asian drivers - you can pick many of the Chinese drivers just by looking at their license plates and checking if they have one or more 8's or 9's (and lack of 4's) in the license plate.

Applies to many number-based items - phone numbers, highrises targeted at Asians may skip the 4th and 14th floors (haven't been in such buildings with more than 20 stories, but I'd assume the pattern would extend to any floor with a 4 in it - no idea about buildings with more than 39 floors)

Once you know about it, it's hard to unsee...

The USA and certain other countries allow a grace period between disclosure of an invention and the patent application for that invention before that invention disclosure becomes prior art. For the USA, the grace period is 12 months, for other countries, it's 6 months.

The SAST program is probably doing a lot more than a string search tool does.

If the SAST has to process C/C++ source code, then the SAST will parse all the #include'd header files. The SAST may track values to determine if illegal/uninitialized values are used.

A string search tool will skip doing all of that.

If the class of problems you're looking for contains only bad functions/constants, then a string search tool may be fine.

But as I mentioned before, the string search tool may get confused if these bad strings occur in strings/comments/irrelevant #if/#else/#elif sections.

There are another class of bugs dealing with data values which a string search tool can't deal with easily.

As an example, PC-Lint lists the type of problems the program may flag - https://www.gimpel.com/html/lintchks.htm. A string search tool won't know about classes and virtual destructors or other concepts relevant to the programming language in question.

For the string search tool, you'd either invoke the search string tool several times with different search strings for the same source code or slightly more efficient, have one long search string containing all your search strings as alternate search targets for the string search tool.

Either case, when the string search tool spits out a positive result, it won't explain why there is a problem. The dev will have to know or lookup the problem associated with that search result.

When I worked on this area, C/C++ compilers stopped at syntax errors. Most have gotten better at flagging popular problems like variable assignments within if statements, operator precedence bugs, and printf-format string bugs.

Some divisions at Microsoft required devs to run a lightweight SAST before committing changes to locate possible problems ASAP.

It's relatively easy to integrate an SAST into your build system to scan the modified source code just before you're ready to commit the changes.

I've gone down this road years ago.

While there's no install and initial results are quick to appear, the false positives that grep or any string search tool generates will make the cynics shoot down this simple attempt to find problems in the source code.

Problems that arose:

- what about use of those questionable APIs/constants in strings (perhaps for logging) or in comments?

- some of the APIs listed in the article were only questionable when certain values were used - sometimes you can get grep/search tool of choice to play along, but if the API call spans multiple lines or the constant has been assigned to a variable that is used instead, then a plain string search won't help.

- it's hard to ignore previously flagged but accepted uses of the API/constants.

- so there's a possible bug reported, but devs usually want to see the context of the problem (the code that contains the problem) quickly/easily. Some text editors can grok the grep output and place the cursor at the particular line/character with the problem, some can't.

If you go down that road to try and reduce false positives, you'll end up with a parser for your development language of choice.